4 ms·

Containers do not stop you to use Chef, Ansible, Puppet or Terraform. Matter of fact, they make it easier for you. We use Terraform to setup new reproducible e

Containers do not stop you to use Chef, Ansible, Puppet or Terraform. Matter of fact, they make it easier for you. We use Terraform to setup new reproducible environments for all of our projects. We have full modules for ECS, EC2 and various others combination of services that we repeatedly use on AWS. It makes it really easy to set something up and not worry about it. Helps us setup bastions, rds, clusters, task definitions, scaling, vpc, alb and all the other things you'd have to waste couple of hours/days to get right.

rumanator 6y ago
If I'm not mistaken, AWS OpsWorks supports Chef and Puppet document formats to configure AWS infrastructure. I've never used it, though. Having said that, it's very weird to hear about using these sorts of tools with containers. The whole point of containers is that they don't require any configuration at all at the container level, because that's already handled when the container image is created. After that point it's a container orchestration problem, and that's left to the Docker Swarm/Kubernetes systems out there.
- bkovacev 6y ago
  Sure, you have CloudFormation templates too, which is AWS own solution as well. There is really multiple ways of doing this. You can always manually set up each server you plan on running as well. My question to you is - but who installs the Docker Swarm or Kubernetes system and make sure it runs and can be accessed by outside world? I think you are missing the point or maybe I am not understanding where you are coming from but in order to bring your code to a server you have multiple layers/steps you go through: - Code layer - Artifact/Image layer (Docker Image) - Orchestration layer (EKS/ECS/Swarm/Compose) - Server Layer (Your local env, any hosted 3rd party server, your on-premise server). First you write the code, then you build it into an image, then you push the image to a registry or directly, then you update your orchestration layer that handles the image. Orchestration layer can't magically setup your server, vpc and other services. Containers do not have anything to do with these tools. They are tools that supplement the workflow. Just like CI is there to help you run the tests, build those images and push them to a registry and trigger updates to your orchestration engine or new deploys, that's how terraform/chef/pupet are there to make configuration changes to those servers.

rumanator 6y ago

If I'm not mistaken, AWS OpsWorks supports Chef and Puppet document formats to configure AWS infrastructure. I've never used it, though. Having said that, it's very weird to hear about using these sorts of tools with containers. The whole point of containers is that they don't require any configuration at all at the container level, because that's already handled when the container image is created. After that point it's a container orchestration problem, and that's left to the Docker Swarm/Kubernetes systems out there.

bkovacev 6y ago
Sure, you have CloudFormation templates too, which is AWS own solution as well. There is really multiple ways of doing this. You can always manually set up each server you plan on running as well. My question to you is - but who installs the Docker Swarm or Kubernetes system and make sure it runs and can be accessed by outside world? I think you are missing the point or maybe I am not understanding where you are coming from but in order to bring your code to a server you have multiple layers/steps you go through: - Code layer - Artifact/Image layer (Docker Image) - Orchestration layer (EKS/ECS/Swarm/Compose) - Server Layer (Your local env, any hosted 3rd party server, your on-premise server). First you write the code, then you build it into an image, then you push the image to a registry or directly, then you update your orchestration layer that handles the image. Orchestration layer can't magically setup your server, vpc and other services. Containers do not have anything to do with these tools. They are tools that supplement the workflow. Just like CI is there to help you run the tests, build those images and push them to a registry and trigger updates to your orchestration engine or new deploys, that's how terraform/chef/pupet are there to make configuration changes to those servers.