[movedx]

At last, someone who gets it. Absolutely nailed it. Great answer. I never log into my HN account anymore, but for this response I just had to say: yes. Well said.

When you boil the Cloud, DevOps, CloudOps, SecOps, *Ops, CI, CD, Containers, VMs, and all the other technologies we've devised over the past ten years, you always end up at the basic building blocks.

You eventually come to the conclusion that all we're really doing with all these new tools is adding software layers on top of those building blocks in an attempt to make them easier and faster to consume.

And how have we done overall?

Not bad, if you ask me. Some solutions are overkill for most people (K8s is an example of over kill for a start up and even an SME.) But Terraform, Ansible and GitLab (CI) are something I'm currently developing a highly opinionated video training course on because I believe they strike the right balance of improving on prior experiences without taking the absolute piss.

[_jwjg]

I am a developer, who also dealt with ops in a small business context. I agree with Ansible striking a good balance between prior experience and the future of automating server configuration.

I did a write-up on how I used it on my blog: [link redacted]

The workflow worked really well, provisioning Vagrant servers in staging and Digital Ocean droplets in production.

[GordonS]

Thanks, I appreciated this blog post - I've struggled to get started with Ansible before, and this was just what I needed!

[movedx]

Nice write up. Good job, mate.

I moved away from Vagrant in favour of Terraform, but I agree Vagrant still holds its own and is a great choice (HashiCorp really nailed it, eh?)

[high_5]

I agree with _dsr, he really nailed it. As for GitLab I agree they got the balance right except that it feels quite Kubernetes centric.

[cpb]

There is a lot of flexibility in the CI/CD configuration. You don't need to use the Kubernetes stuff.

[vageli]

Curious about where you see ansible fit in while using Terraform, could you expand on that? Everywhere I have thought I would need ansible to scratch an itch it has turned out that terraform has that functionality in some way (through null_resource, runners).

[movedx]

Terraform is for managing infrastructure. Ansible is for managing configuration. You can argue they're the same thing, but I disagree.

I believe in one tool to do one job really well.

Terraform is excellent at provisioning and managing infrastructure due in part to its DAG and HCL. On the other hand Ansible has been tuned over the years for managing configuration and the state of anything and everything from the OS upwards.

I also believe in using building blocks to get to where you're going, and these two bad boys click together quite well.

[vageli]

I guess what I'm questioning is the place of configuration management tools in a world of increasingly managed services where the server is not patched by you. In those cases, it makes no sense to me to patch individual containers through automation versus updating the image and pushing out the artifact to the service so all containers everywhere are updated and there's no checking for variance in state since all are running the same (updated) image.

[wokwokwok]

personal experience only, but like Dockerfiles, terraform is only good for provisioning until its not.

Once your VM or container hits a complexity point above trivial, ansible is very much a useful tool for provisioning container states, and specifically for patching container images to, eg. include security updates.

...beyond that, as in, the intended use case of dynamically updating multiple live machines in parallel... dunno, I don’t use ansible for that... but it beats the hell of out having a single monolithic batch script to setup a container. I use it for that purpose all of the time.

[vageli]

I guess that's the disconnect for me. Why would I want to update individual containers when I can just push out a new image and have automation rotate my services? Individually applying security patches at the container level also means there's probably SSH access as well, something I am quick to remove in environments in which I encounter it.

For host based security patches (if I'm in an environment where the servers aren't managed), adding an item to the crontab in user data usually handles that, and again any fleet-wide changes would usually be propagated by updating the user data, pushing out the change and having automation rotate the fleet.