Circular Dependency on ECR artifact

Question

Circular Dependency on ECR artifact

lyoungblood opened this issue 6 years ago · 5 comments

This is such a powerful architectural pattern, @jpignata - especially with Fargate.

I just wanted to make you aware of a circular dependency issue. I couldn't figure out an elegant workaround. Since you are creating a brand new ECR repository that will have zero artifacts until you do a successful build, the ECS service will never complete creation because the task can't move from PENDING to RUNNING state until it can pull the artifact from ECR. And, the Pipeline can't create yet because it needs an ECS service to deploy to.

The workaround I am currently using is to launch the CloudFormation template, then while the ECS Service is attempting to launch, doing a manual "docker build/tag/push" to the newly created ECR repository. Once there is an artifact to pull, the ECS service goes to CREATE_COMPLETE status and the Pipeline gets created.

This probably wouldn't be an issue if you're using a pre-existing ECR repository with at least 1 artifact.

Answer 1 · 2018-05-13T16:26:28.000Z

The template has an inelegant workaround in place whereby it first pulls a generic container from Docker Hub. I hate this, but it worked for me in testing. Did you see differently? I suspect having a CloudFormation template in the pipeline to manage the task definition and service is less problematic than the native ECS/CodePipeline integration, FWIW.

…

On Sat, May 12, 2018 at 8:13 PM Luke Youngblood ***@***.***> wrote: This is such a powerful architectural pattern, @jpignata <https://github.com/jpignata> - especially with Fargate. I just wanted to make you aware of a circular dependency issue; I couldn't figure out an elegant workaround. Since you are creating a brand new ECR repository that will have zero artifacts until you do a successful build, the ECS service will never complete creation because the task can't move from PENDING to RUNNING state until it can pull the artifact from ECR. And, the Pipeline can't create yet because it needs a running ECS service to deploy to. The workaround I am currently using is to launch the CloudFormation template, then while the ECS Service is attempting to launch, doing a manual "docker build/tag/push" to the newly created ECR repository. Once there is an artifact to pull, the ECS service goes to CREATE_COMPLETE status and the Pipeline gets created. This probably wouldn't be an issue if you're using a pre-existing ECR repository with at least 1 artifact. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#41>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABNP51tfpzFeKQAnb9YIFhQAYCix-cZks5tx3qUgaJpZM4T8m2z> .

Answer 2 · 2018-05-14T17:57:08.000Z

Would you mind pointing out where in the code that workaround is? I actually rewrote this entire architecture pattern into a single template so that I didn't have that issue that others faced if they wanted to update stack (where you lose the ability to change parameters as part of a stack update, or potentially have stack updates override parameters causing unexpected behavior).

Answer 3 · 2018-05-14T18:02:17.000Z

I also agree about your second statement (having a CloudFormation template in the pipeline to manage the task definition and service) - it seems somewhat against the "infrastructure as code" paradigm to have a service like CodePipeline updating the task definition for you, as opposed to versioning that in source control like everything else. Perhaps if I have enough free time I'll take a stab at it and create a pull request.

Answer 4 · 2018-05-14T19:46:59.000Z

See #33 for discussion on this.

…

On Mon, May 14, 2018 at 2:02 PM Luke Youngblood ***@***.***> wrote: I also agree about your second statement (having a CloudFormation template in the pipeline to manage the task definition and service) - it seems somewhat against the "infrastructure as code" paradigm to have a service like CodePipeline updating the task definition for you, as opposed to versioning that in source control like everything else. Perhaps if I have enough free time I'll take a stab at it and create a pull request. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#41 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABNP8w9XdweYNNLJNjWMkMekYFetGbEks5tycasgaJpZM4T8m2z> .

Answer 5 · 2018-05-14T22:40:00.000Z

See
#33 for
discussion on this.

Great! That actually looks like a better option, to deploy with DesiredCount 0. By merging all the nested templates into 1, I've already fixed the issue with parameter overrides in the nested templates getting overwritten by stack updates.