Answers: <p>You're comparing apples with oranges according to your description. A strict comparison could be packer toward dockerfile, and/or terraform toward kubernetes yaml for example.</p>
  
  <p>Main difference between your docker pipeline and your packer/terraform one is the architecture behind them.<br>
  What is putting the burden here is that your AWS infrastructure doesn't take advantage of auto-scaling groups rolling updates, or your 'stage-gates' in go does disrupt them.</p>
  
  <p>You're not comparing docker with terraform, you're comparing rancher with your AWS infrastructure choices. If you don't use the equivalent bricks of rancher load balancing and deployment groups (kubernetes wording here) which are Elastic Load Balancers and Auto Scaling Groups in AWS you can't compare them.<br>
  That's saying a car and an bicycle does the same thing (transportation) with a better result for the car, put a motor on the bicycle and you'll have a far different appreciation and something less biased.</p>
  
  <p>Your observation is pointing out that your usage of AWS facilities is sub optimal, terraform (or whatever provisionning system) can't help you more than running things, if your architecture is not made (in the terraform file) to allow rolling updates from this facility, no automatic system will fix it for you as you'll have to code it again (test instances status, etc.).</p>
  
  <p>Of course rancher pre-bake most of those, making them invisible to you. This also mean you are enforced in rancher methodology (well, swarm, kubernetes or messos architecture to be exact).<br>
  That's the main difference, on one side you have an infrastructure already ready to serve with rancher and you can't run outside it, and on the other side you have to think your architecture before hand. If you were to run docker containers on a bare docker host (without any orchestrator on top) you'll end up with the same architecture design to think before hand and the same caveats you're seeing on AWS.</p>
  
  <p>AWS is not strict on how you use it, it's an infrastructure as a service with no opinion on how you use it, whereas rancher enforce a bunch of services around your own container to save you the design time as long as you accept the constraint within it.</p>
  
  <p>Hope this help seeing the problem from an upper level and as such I think the answer to your questions is that you were missing a pattern ;)</p>
  
  <p>For the records: we're doing deployments on AWS with cloudformation (native version of terraform, with its own caveats) from  a push on a gitlab server and it works nicely, the work to get proper cloudformation templates and the script to run it was non negligible. This to say the tools are not the problem, it's all a design choice at a point, same results can be achieved, arncher comes with its own caveats and design choices to make when you integrate it into an existing infrastructure. </p>
  
Answers: CC BY-SA 3.0
Answers: 2017-05-22T12:43:38.650Z
Answers: 2017-05-22T12:43:38.650Z
Answers: Tensibai
Body: <p>At work we have a <a href="https://www.thoughtworks.com/go/" rel="nofollow noreferrer">Go</a> <a href="https://devops.com/continuous-delivery-pipeline/" rel="nofollow noreferrer">CD pipeline</a> for producing <a href="https://www.docker.com/" rel="nofollow noreferrer">docker</a> <a href="https://docs.docker.com/engine/reference/commandline/images/" rel="nofollow noreferrer">images</a>, and scheduling docker containers with <a href="http://rancher.com/rancher/" rel="nofollow noreferrer">rancher</a>. </p>
  
  <p>This works quite well. You can <a href="https://git-scm.com/docs/git-commit" rel="nofollow noreferrer">commit</a> a change to the Docker image in <a href="https://en.wikipedia.org/wiki/Git" rel="nofollow noreferrer">Git</a>, the pipeline will pick it up, and upgrade the container. (The CD pipeline tags the version of the docker image with the build number of the pipeline, and this provides continuity throughout the upgrade.)</p>
  
  <p>We have a similar arrangement with AWS AMIs using <a href="https://www.hashicorp.com/" rel="nofollow noreferrer">Hashicorp</a> <a href="https://www.packer.io/" rel="nofollow noreferrer">Packer</a> and <a href="https://www.terraform.io/" rel="nofollow noreferrer">terraform</a>. You can make a change to a packer json file in git, the pipeline will rebuild a new AMI.  Given the user's approval in Go (we have some stage-gates in Go) this can then in theory to stop the existing ec2 instance and start a new one based on the AMI that was built. (The ID of the AMI is passed through the pipeline.)</p>
  
  <p>In practice terraform doesn't work quite as well in a pipeline. (Compared to docker). Sometimes it is just the sheer complexity of things associated with an EC2 instance and corresponding VPC/routing arrangements can tangle it. Sometimes it is that you need to custom-write your own tests to see if the EC2 instance was stopped, and then started. </p>
  
  <p>Is there a broader consensus on this issue? Are there some patterns I'm missing? Or is it just that when you're on the bleeding edge, things hurt a bit?</p>
  
  <p>My question is: <strong>How does using packer and terraform in a CD pipeline compare to docker images built from git?</strong></p>
  
Comments: CC BY-SA 3.0
Comments: 2017-05-21T00:10:13.483Z
Comments: I'm a fan of CI/CD, but I'd be afraid that terraform's tendency to want to recreate the world from scratch doesn't fit with the waterfall nature of pipelines.
Comments: chicks
Comments: CC BY-SA 3.0
Comments: 2017-05-21T04:19:04.090Z
Comments: Great observation- Terraform does have a global not local approach. Are there any other tendencies or terraform you'd like to mention?
Comments: hawkeye
Comments: CC BY-SA 3.0
Comments: 2017-05-21T05:45:35.773Z
Comments: https://objectpartners.com/2016/06/01/automating-terraform-projects-with-jenkins/ shows that some people have made this work so maybe you can too.
Comments: chicks
Comments: CC BY-SA 3.0
Comments: 2017-05-21T20:16:36.610Z
Comments: This question might be easier to answer as "how do these solutions compare?", rather than "please support my assertion that this solution is a bad idea".
Comments: Martin Atkins
Tags: <docker><amazon-ec2><terraform><packer><gocd>
Title: How does using packer and terraform in a CD pipeline compare to docker images built from git?
UserDisplayName: hawkeye
ThreadText: # How does using packer and terraform in a CD pipeline compare to docker images built from git?
  
  (Asked by: username_0 on 2017-05-20)
  
  At work we have a [Go](https://www.thoughtworks.com/go/) [CD pipeline](https://devops.com/continuous-delivery-pipeline/) for producing [docker](https://www.docker.com/) [images](https://docs.docker.com/engine/reference/commandline/images/), and scheduling docker containers with [rancher](http://rancher.com/rancher/).
  
  This works quite well. You can [commit](https://git-scm.com/docs/git-commit) a change to the Docker image in [Git](https://en.wikipedia.org/wiki/Git), the pipeline will pick it up, and upgrade the container. (The CD pipeline tags the version of the docker image with the build number of the pipeline, and this provides continuity throughout the upgrade.)
  
  We have a similar arrangement with AWS AMIs using [Hashicorp](https://www.hashicorp.com/) [Packer](https://www.packer.io/) and [terraform](https://www.terraform.io/). You can make a change to a packer json file in git, the pipeline will rebuild a new AMI. Given the user's approval in Go (we have some stage-gates in Go) this can then in theory to stop the existing ec2 instance and start a new one based on the AMI that was built. (The ID of the AMI is passed through the pipeline.)
  
  In practice terraform doesn't work quite as well in a pipeline. (Compared to docker). Sometimes it is just the sheer complexity of things associated with an EC2 instance and corresponding VPC/routing arrangements can tangle it. Sometimes it is that you need to custom-write your own tests to see if the EC2 instance was stopped, and then started.
  
  Is there a broader consensus on this issue? Are there some patterns I'm missing? Or is it just that when you're on the bleeding edge, things hurt a bit?
  
  My question is: **How does using packer and terraform in a CD pipeline compare to docker images built from git?**
  
  **Tags:** docker, amazon-ec2, terraform, packer, gocd
  
  > **Comments:**
  > **username_1**: I'm a fan of CI/CD, but I'd be afraid that terraform's tendency to want to recreate the world from scratch doesn't fit with the waterfall nature of pipelines.  
  > **username_0**: Great observation- Terraform does have a global not local approach. Are there any other tendencies or terraform you'd like to mention?  
  > **username_1**: https://objectpartners.com/2016/06/01/automating-terraform-projects-with-jenkins/ shows that some people have made this work so maybe you can too.  
  > **username_2**: This question might be easier to answer as "how do these solutions compare?", rather than "please support my assertion that this solution is a bad idea".  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_3 on 2017-05-22. Score: 2 | Accepted answer
  
  You're comparing apples with oranges according to your description. A strict comparison could be packer toward dockerfile, and/or terraform toward kubernetes yaml for example.
  
  Main difference between your docker pipeline and your packer/terraform one is the architecture behind them.  
  What is putting the burden here is that your AWS infrastructure doesn't take advantage of auto-scaling groups rolling updates, or your 'stage-gates' in go does disrupt them.
  
  You're not comparing docker with terraform, you're comparing rancher with your AWS infrastructure choices. If you don't use the equivalent bricks of rancher load balancing and deployment groups (kubernetes wording here) which are Elastic Load Balancers and Auto Scaling Groups in AWS you can't compare them.  
  That's saying a car and an bicycle does the same thing (transportation) with a better result for the car, put a motor on the bicycle and you'll have a far different appreciation and something less biased.
  
  Your observation is pointing out that your usage of AWS facilities is sub optimal, terraform (or whatever provisionning system) can't help you more than running things, if your architecture is not made (in the terraform file) to allow rolling updates from this facility, no automatic system will fix it for you as you'll have to code it again (test instances status, etc.).
  
  Of course rancher pre-bake most of those, making them invisible to you. This also mean you are enforced in rancher methodology (well, swarm, kubernetes or messos architecture to be exact).  
  That's the main difference, on one side you have an infrastructure already ready to serve with rancher and you can't run outside it, and on the other side you have to think your architecture before hand. If you were to run docker containers on a bare docker host (without any orchestrator on top) you'll end up with the same architecture design to think before hand and the same caveats you're seeing on AWS.
  
  AWS is not strict on how you use it, it's an infrastructure as a service with no opinion on how you use it, whereas rancher enforce a bunch of services around your own container to save you the design time as long as you accept the constraint within it.
  
  Hope this help seeing the problem from an upper level and as such I think the answer to your questions is that you were missing a pattern ;)
  
  For the records: we're doing deployments on AWS with cloudformation (native version of terraform, with its own caveats) from a push on a gitlab server and it works nicely, the work to get proper cloudformation templates and the script to run it was non negligible. This to say the tools are not the problem, it's all a design choice at a point, same results can be achieved, arncher comes with its own caveats and design choices to make when you integrate it into an existing infrastructure.
  
  
  ---
  
  