We are about to begin our journey with containers and I am wondering if we still need to utilize something like Chef, Ansible, Terraform, etc. to ensure that our infrastructure is properly maintained?
Since containers simply sit on that environment my assumption is that we will still need to properly maintain our configuration idempotence but how is this going to differ with us using containers?
It depends on what you are willing to rent and allow to be managed by someone else.
If we look at this diagram:
It shows a full range of options. At one end is Do It Yourself with on-prem hardware and setting up networks etc. Next to that is ”co-lo” which implies you buy servers that are installed in someones rack/network/data centre. Next to that is IaaS where you usually rent VMs on purely software defined networks and pay someone to manage the physical servers and physical network.
So where do containers fit in? Well I have seen big organizations treat cloud IaaS a bit like on-perm by setting up networks and firewalls in cloud to exactly match on-prem with private network connections into the cloud datacenter. So getting very little advantages of cloud. What they are mostly managing are dozens of legacy systems that they have ”lifted and shifted” from on-prem into a cloud provider as part of a multiple million dollar cloud contract. Obviously, they still need all the configuration management like they were using on-prem to manage the VMs. Then they install Kubernetes to manage containers and have to manage that. The cost of all the engineers they need to hire to keep it all running is huge. In such a setup its clear they need configuration management at every level and clusters of containers are just one more new thing they need to configure and manage.
At the other end of the spectrum is SaaS and you don't know if they use VMs or Containers. You then have no traditional configuration management and usually no devops. From the devops perspective an interesting choice is CaaS+PaaS where you rent capacity on a managed Kubernetes service that has devops extensions such as OpenShift. As a start up you can simply rent memory on a shared cluster where you are isolated from other tenants via software defined networks within OpenShift Kubernetes. Then you have outsourced both management and configuration of the VMs in the cloud and also outsourced patching and expanding the Kubernetes cluster running on the VMs. You can then focus on configuration management of your containers on Kubernetes. (Note: You still need to security patch the container runtimes. We have a script that checks for new security patches to RHOAR containers and rebuilds our containers with the latest versions.)
So it depends on how much you can and are willing to relinquish control of. Its easy to start out renting a fraction of a shared managed cluster then upgrade to a dedicated cluster still managed by someone else. Once you start out doing that on public cloud its hard to imagine any additional advantage of going back to managing VMs in the cloud. Unless you are forced to do so to run legacy apps or software you had to buy that doesn't support being run in containers. If you must configure VMs you should apply best practices of configuration management.
Welcome to containers, a very exciting direction indeed.
Software configuration management tools such as the ones you mention do cater for containers in many ways and if you're already familiar with Terraform then you'll probably already know this.
Kubernetes for instance can manage deployments and replication sets (of containers; 'pods') and nodes much like Puppet might manage virtual machines and micro-services.
I would say I personally use Puppet less in the container world but believe configuration management is still necessary in a container infrastructure though you may change the way you approach it with regard to the native tools that come along with containers as opposed to Puppet perhaps.
A Dockerfile is fairly self explanatory to satisfy the infrastructure as code perspective that Puppet delivers; and if you then get into Kubernetes clusters and nodes the same could be said about YAML files too.
Containers are bundles of repeatable infrastructure. I find this stack overflow answer supports my answer too; it certainly helped me in the past.
