Hacker News Reader

Comment by rocgf | Hacker News Reader

I'm not a very versed DevOps guy, but I have used Ansible, Terraform and Kubernetes.

It should go a bit like this:

- Use Terraform to provision VMs, networking resources and storage from DigitalOcean. Basically, write the scripts that make your whole infrastructure available with a single command.

- Then use Ansible for anything you might want installed on those machines - Kubernetes, security packages, SSH keys for your team.

- Use Kubernetes to then deploy your application on top of your secure and replicable infrastructure.

Each of the steps above should be roughly one shell command. If you are disciplined enough to always provision machines, install packages and deploy your app via config files, this should be very much achievable.

View on HN

>- Use Terraform to provision VMs, networking resources and storage from DigitalOcean. Basically, write the scripts that make your whole infrastructure available with a single command.

How does autoscaling work if terraform/ansible are involved before kubernetes can take over?

IMO it's better for autoscaling to bake VM images and use cloud-init or similar to add per-instance config tweaks if necessary. Using Ansible to do runtime configuration is slow and doesn't play well with autoscaling. I do like Ansible, however, and use it for building EC2 AMIs. I even wrote a tool for this purpose at https://github.com/cloudboss/bossimage.

There are generally two levels of autoscaling involved with kubernetes.

Firstly, kubernetes is able to create multiple instances of your app as load increases and scale them out over all the nodes.

Secondly, the nodes your kubernetes cluster is running on can also autoscale. With terraform you can set up an AWS autoscaling group for example to automatically increase the size of your cluster as load increases.

Hey just curious:

With a dockerfile is there any point to using Ansible/Puppet/Chef any more? I have used those tools to keep 'how machines are installed' in code in the past, but with dockerfiles these days I don't get the point anymore. Seems like the future will be having a few dockerfiles (staging, prod, dev, db, etc) then just finding a place to run them (digital ocean, docker swarm, aws container service - or your macbook).

You still have to bootstrap the instances/droplets/etc with Docker, Kubernetes, etc before Dockerfiles can be used. Unless you're starting with images where those are already baked in, Ansible/Chef/Puppet are good ways to accomplish this on a clean OS.

It's debatable. Ansible/Chef/Puppet themselves need to be bootstrapped as well.

Bash is perfectly fine if the machine can be installed with less than 100 lines of code and immutable infrastructure is being used (so no need for idempotent operations). Just make sure to add ShellCheck to the CI pipeline.

Ansible/Chef/Puppet themselves need to be bootstrapped as well.

Nope, Ansible just needs SSH access.

Remote hosts need Python, but you can use the raw command functionality to figure out what the remote package manager is and install Python as required.

Not when using AutoScaling Groups. Then the machine will be provisioned on boot and therefor ansible would have to be installed on the machine.

No, you'd use Ansible to prepare the new image once, then you'd use that image to scale. Bootstrapping everything each time a VM is created doesn't make much sense.

> Bash is perfectly fine if the machine can be installed with less than 100 lines of code

It is always tough to predict the future; something < 100 lines can easily grow over time. It is nice to start with a tool like Chef/Ansible/Puppet which can more easily grow as the project grows vs Bash.

I agree that it's hard to predict the future, that's why I'm not trying to add unnecessary dependencies. 100 lines of code are not hard to rewrite in anything else if necessary.

I'm doing just that (for a SaaS).

1. Build an AMI with Packer that contains Ubuntu + Docker + aws-cli.

2. Build and publish docker images for all the services that will run on the instances. (one image per service, not per environment like you suggested)

3. Configure the EC2 instance or AutoScaling Groups with userdata. The userdata usually just contains a `docker run ...` instruction.

I used to have Chef, run test kitchen, bake AMIs, cycle all the machines. Now I have a single AMI and do most of the testing on the docker side and then some on staging. In both cases I am using terraform to manage the overall infrastructure (and userdata scripts).

The only issue is how to manage secrets as userdata are readable with the DescribeInstance ACL. The best solution that I found is to upload the secrets on S3+KMS and use IAM Role on the machine to retrieve them. Or use Hashicorp Vault.

For single-provider solutions, I'd say that's debatable. You might be fine with <insert cloud provider here>'s PaaS spin-up services for Kubernetes. The instant you want to span multiple cloud providers, you'll rub up against all the minor differences between each of their implementations, and I think that's where the value in SaltStack/Ansible/Chef/Puppet is in modern times. Manually orchestrate your infrastructure once, then deploy it to any cloud provider.

I moved away from dockerfiles to Packer to build images for multiple environments. Even if you don't need that, ansible from dockerfile is a good choice to avoid writing hard to manage/reuse scripts in yml

I don't think it's a good idea to have different dockerfiles for your staging, dev and prod environments.

The point of using Docker containers is that you get to deploy to production your dev environment as is.

No, you don't need those tools anymore.

Cook a base VM image that has the docker engine and anything else you need. Do this once and spin up VMs you need after that. This is what images are for, and they're far easier, faster, more reliable and more secure than dealing with all this other junk.

How do you do the cooking of the base VM image?

All the major clouds already have API commands to convert a VM into a reusable image - so a simple startup script + this API command is all you need. Even better since you can script all this too.

If anything changes, update the startup script, then run this "make new base image" script and you're all set. Update VMs as needed. Really doesn't get much more complicated than that and using tools like ansible just to setup your VMs so you can run docker containers later is unnecessary.

You make Ansible sound like an ICBM launching system. In practice, you do a simple "apt install ansible" once (on your machine) and then you write a simple startup script in it. There's nothing extra to be "unnecessary", it's a 1:1 replacement.

Why do you need that then when you can just use the startup script directly with the VM?

Unnecessary = not needed to function. Replacing functionality is just preference, which is fine, but specifically not necessary.

Why do you need that then when you can just use the startup script directly with the VM?

My point is that's a loaded question. You could just as easily ask why do you need bash in every VM when you can just have Ansible in a single machine.

Check out Packer (https://www.packer.io/intro/)

Could you point to any articles that go into a bit more depth on this provisioning-configuration-deployment flow?

You can use Ansible for step one, too. And I think I'd recommend it highly over Terraform for production provisioning.

> I think I'd recommend it highly over Terraform for production provisioning.

I'm curious why you recommend this? I'd argue the opposite. With the declarative nature of Terraform, you can know exactly which part of your infrastructure is going to change before you actually apply it. With Ansible, this information is a bit more opaque. You basically just run the playbook and pray it goes as planned and things haven't drifted too much.

You can run Ansible in check mode and see what steps will make changes.

Reply on news.ycombinator.com