How to deploy frontend and backend in one CICD (CodePipeline)?

0

I have set up a CICD for the frontend of my App which is using Codepipeline, Code Build, and it deploys frontend of my app to ECS Fargate container. Similarly, I have setup a CICD for backend of my App which is also using Codepipeline, Code Build and it deploys backend of my app to ECS Fargate Container.

The problem is that both frontend and backend of my application are in two different Bitbucket repositories. Is there any good practice to manage this in one CICD. Basically, I want to deploy my app's frontend and backend to one ECS Fargate cluster. Right now two ECS Fargate clusters are being used. I just want to deploy my application as one solution which eventually contains two containers but in a single cluster.

I am following this tutorial if someone wants to get more details.

Is there any best practice that I should follow for my solution? Any suggestion for the improvement will be appreciated greatly.

2 Answers
1
Accepted Answer

Hi,

Zainub here. It will be my pleasure assisting you on this query.

From the correspondence, I understand that:

  • There currently are 2 separate pipelines for the front-end and backend of the application.
  • The front-end and backend of the application are in different BitBucket repositories.
  • Guidance is required on best practices for managing the front-end and backend in one CICD pipeline.
  • The front-end and backend must be deployed to 1 ECS cluster with 2 containers - currently being deployed to 2 clusters.

Kindly confirm if the summary and understanding of the issue is correct.

Best Practice

As per the CICD best practices on AWS, it is recommended to:

"Use multiple distinct pipelines for each branch and team"

In this case, the best practice would be to use distinct pipelines for each repository.

That said, it may still be possible to deploy to 1 cluster with each container running in it's own service. See Step 2: Creating Your Continuous Deployment Pipeline point 6 to add a deployment stage, specifying an existing ECS cluster and service. The difference between the front-end and backend pipelines will be that they specify the same ECS cluster but different services.

However, I see that the 3rd party tutorial uses a CloudFormation (CFN) provider in the deploy stage which creates the Fargate ECS Cluster with a VPC, 2 Subnets and a Load balancer. This solution creates the infrastructure, therefore, when used on 2 different pipelines, 2 clusters are created. A suggestion would be to deploy the CFN template separately, so that the infrastructure is created only one time and include the ECS cluster in the pipeline as an existing cluster.

Kindly note that assistance on custom solutions falls beyond the level of support generally provided. As such, I have not personally implemented this custom solution and guidance, regarding this, is provided on a best effort basis.

Update The Custom Solution

That said, if you would still like to implement 1 pipeline to deploy the front-end and backend containers to a single cluster, this is possible. However, kindly note that implementing such a solution means that if there is a change deployed from 1 repository, the pipeline deployment will execute for both repositories.

Update The Source Stage

It is possible to configure the pipeline to pull from multiple sources.

If multiple source input artifacts are configured, such as for the front-end and backend BitBucket repositories, ensure that multiple source output artifacts are also configured.

Update The Build Stage

Update the build stage input artifacts to include the multiple source output artifacts. According to the custom solution, the source output artifact is manipulated in the build and a file, imageDetail.json, is included as the build output artifact. The build must be updated to include output artifacts for the front-end application and the backend application.

Update The Deploy Stage

Update the deploy stage input artifacts to include the multiple build output artifacts. Additionally, update the ParameterOverrides to include an image URI for the front-end and backend application.

Update Fargate-Cluster.yml

Update the Fargate-Cluster.yml to either include a TaskDefinition for the front-end and backend application (2 tasks running in one cluster) or update the TaskDefinition's ContainerDefinitions to include a container for the frontend and backend application (1 task running in the cluster which contains 2 containers).

A summary of the steps required to update the custom solution is as follows:

  • Note: If there is a change deployed from 1 repository, the pipeline deployment will execute for both repositories.
  • Update the source stage to include multiple source input and output artifacts (for front-end and backend).
  • Update the build stage:
    • Include multiple input artifacts.
    • Update the build itself to create and include multiple output artifacts.
  • Update the deploy stage:
    • Include multiple input artifacts.
    • Update the ParameterOverrides to include an image uri for the front-end and backend application.
  • Update the TaskDefinition to either:
    • Include a task definition for each application.

      OR

    • Update the TaskDefinition to include a container for each application.

Kindly note that as assistance on custom solutions falls beyond the level of support generally provided, I have provided a high level overview of the changes required to the custom solution on a best effort basis.

Additional Information

The following documentation, regarding CICD best practices, may also be of interest:

I hope you find the above informative and don't hesitate to reach out with further questions!

Have a great day ahead.

Resources:

Summary of best practices

Tutorial: Amazon ECS Standard Deployment with CodePipeline: Step 2: Creating Your Continuous Deployment Pipeline

Multiple input sources and output artifacts sample

CodePipeline best practices and use cases

Security best practices

AWS
SUPPORT ENGINEER
answered a year ago
profile picture
EXPERT
reviewed 10 months ago
  • Hi Zainab, thank you for the detailed explanation. I just want to clear one more thing. As you have mentioned above, "A suggestion would be to deploy the CFN template separately, so that the infrastructure is created only one time and include the ECS cluster in the pipeline as an existing cluster". I just want to know that when when CFN template runs again it doesn't only update the existing resources or recreate them? I think it should only update the infrastructure only. Kindly share your feedback on this. I will be waiting for you. You have assisted me remarkably.

0

Hi,

From the comment, I understand that guidance is required on whether deploying the CFN template again would update the existing resources or recreate them. Kindly confirm if the summary and understanding of the issue is correct.

If the solution had not yet been implemented, then you would need to deploy the Fargate-Cluster.yml stack template directly on CFN to create the ECS resources. That is to say, it is not necessary to deploy the Fargate-Cluster.yml stack, you would just need to update the deploy stage provider to specify ECS. Kindly note that this is a high level overview of changes that would need to be made and as you work to change the custom solution, more detailed changes may be needed.

As the solution has been implemented:

  • A template deployment to the existing stack is only necessary when you want to update the infrastructure.
  • Depending on the resource property changes, the resources will either be updated or replaced.
  • If you do not deploy the template to the existing stack and choose to create a new stack, new resources will be created.

As always, I hope you find the above informative and don't hesitate to reach out with further questions.

Have a great day further.

Resources:

AWS::ECS::Service Properties: DeploymentController

AWS::ECS::Service Properties: CapacityProviderStrategy

Update behaviors of stack resources

AWS
SUPPORT ENGINEER
answered a year ago
profile picture
EXPERT
reviewed 10 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions