s3 frontend and backend in copilot for the pipeline

[rxmatch]

Hello, can anybody guide me in this situation?

My scenario:
I have a frontend build (react.js app) served from an S3 bucket.
And the backend uses ec2 as a cluster for ECS, which I would like to migrate to copilot with Fargate provisioned.

My current deployment is done with two GitHub actions, a backend deploys action and then a frontend deploys action.
Basically, the frontend deploys actions build and sends the files to the bucket and the backend deploys action does a local build of the Dockerfile, uploads the image to ECR, compiles the task definition, and then creates the ECS service with this task definition and the ECR image, basically what copilot solves but I didn't know about this tool until recently.

Now I feel like incorporating copilot and using the pipeline functionality too, but I don't want to create a service with an Nginx to serve my frontend, I would like to take advantage of the pipeline to deploy the backend and then deploy the frontend as a dependency, but since it is not a copilot service I can't set that dependency and get it to work, like:

stages:
    - name: testing
      deployments:
        api:
        front:
          depends_on:
            - api

I thought about using a scheduled job disabled to create a front job and use it in the pipeline definition with a Dockerfile that would copy the files to the S3 bucket but I got the following error: File [infrastructure/front-specific-feature.params.json] does not exist in artifact [BuildOutput], but in fact, I think it would not be a solution because if it failed, my frontend version would be out of sync with the backend version. I don't know if this can be achieved with pipeline anyway.

Someone can guide me on how to realize this using copilot if it is possible? many thanks!

[efekarakus]

Hi @rxmatch !

That's a really cool use case that totally makes sense.

Mitigation

This isn't an ideal solution, but please let me know what you think. Is it possible to leverage the test_commands to potentially upload the React app to the s3 bucket?

stages:
- name: testing
  deployemnts:
     api:
  test_commands:
     - aws s3 cp webapp/ s3://mybucket/ --recursive # Option 1.
     - copilot task run  --dockerfile ./s3uploader/Dockerfile --task-role <some role with access to s3>  # Option 2.

The main downside of Option 1 that I can think of is that you'll have to modify the BuildProjectPolicy outside of Copilot to give permission to upload artifacts to the s3 bucket:

copilot-cli/internal/pkg/template/templates/cicd/pipeline_cfn.yml

Lines 42 to 46 in eb8ad5a

	BuildProjectPolicy:
	Type: AWS::IAM::Policy
	DependsOn: BuildProjectRole
	Properties:
	PolicyName: !Sub ${AWS::StackName}-CodeBuildPolicy

My teammate is currently working on #2755 so that we can specify additional permissions with the pipeline manifest.

Option 2 should just work, but you'd need to write a small script that can upload the react app to the s3 bucket.

Feature Request

[preferred] A CodeBuild action

In the long run, it sounds like it might be to nice to provide an action that can run copilot task run that translates to a CodePipeline action of type Build and provider CodeBuild

stages: yaml
- name: testing
  deployments:
     api:
     frontend:
        commands:
          - copilot task run --dockerfile ./s3uploader/Dockerfile
        depends_on:
          - api

S3 Deploy Action

Another alternative is the S3 Deploy Action.

stages: yaml
- name: testing
  deployments:
     api:
     frontend:
        s3:  
           from: ./webapp/
           to: mybucket 
        depends_on:
          - api

I'm not yet clear on where the IAM permissions for the bucket should be specified, I assume it's the pipeline role.

[rxmatch]

hi @efekarakus !

thank you very much for your time and your detailed answer, I really appreciate it!

For now and for reasons of time, I'm going to opt for a different solution in which I'm going to simply handle the deploys separately, but I think that the proposed solution using test_commands should work! it had crossed my mind but I wasn't convinced completely use that place to reach that goal.

Also, I think a good use case came out of here and the feature request that you expressed here could be a very good solution and definitely going to be a good way to go.

Thank you very much again!