Live data from Hacker News

Creating my personal cloud with HashiCorp

cgamesplay.com

41–50 of 90 posts

Re: Creating my personal cloud with HashiCorp

#41
post #5

As a DevOps guy, I'm not a huge fan of Terraform. Often I hear from enterprises that Terraform is cloud agnostic, but that's often very wrong. Terraform modules are still specific to the cloud platform and a rewrite is required to port an app running on AWS to GCP. If you use AWS, you're probably better off to use AWS Cloudformation and for GCP Google Cloud Deployment manager. A business reason is often that the engi…

> I'm not saying Terraform is not good, but I just think a native solution of the platform is preferable over a 3rd party tool.

I would agree if you have your green-field approach and can commit to a single platform.

From my current experience I use AWS, Azure some other SaaS hosted products like ElasticSearch, Instana, Opsgenie, Kubernetes, databases, Grafana, Prometheus. And with all these products you have a bunch of people in the companry which specialize in their domain and can't know all the tools in all details but have to talk to each other.

So what makes terraform so special in my case is that you can streamline the interaction between multiple teams by focusing on defining well-known interfaces between those teams. The interfaces in the case of terraform would be:

variables (inputs)

outputs

Or you can have specialized teams, which will offer terraform modules for other teams to use.

So for me terraform does not have to be agnostic as this is not the point of it. The benefit of terraform is to streamline interactions (inputs,outputs) for your needs. Teams could automate their things with a python script for example, and use terraform just as a "hull" to offer a way to pass inputs,args to you python script and report back some outputs.

What a Dockerfile did, was to establish a well-known interface on how to define what a container is, by giving a standard-way on how to declare a "CMD,ENTRYPOINT,PORT,etc."

And terraform in that sense gives you a standard on how to define your inputs,outputs when you build,configure infrastructure,Saas, etc.

Re: Creating my personal cloud with HashiCorp

#42
post #16

the qemu driver for nomad seems pretty bare bones compared to kubevirt https://www.nomadproject.io/docs/drivers/qemu https://kubevirt.io/user-guide/virtual_machines/disks_and_vo... Is terraform generally used to deploy workloads to nomad instead of writing tasks directly?

With the Nomad qemu driver, any unsupported options (like bridge networking) can be passed as args.

Re: Creating my personal cloud with HashiCorp

#43
Great article. I’ve also just started using nomad to manage personal services on my home loan.

What I particularly like is that I have a mixture of Docker containers, VMs, and LXD containers all centrally managed.

Overall I found nomad to be fairly intuitive, and the single binary/single job paradigm of the Hashicorp stack is very appealing.

Re: Creating my personal cloud with HashiCorp

#44
post #5

As a DevOps guy, I'm not a huge fan of Terraform. Often I hear from enterprises that Terraform is cloud agnostic, but that's often very wrong. Terraform modules are still specific to the cloud platform and a rewrite is required to port an app running on AWS to GCP. If you use AWS, you're probably better off to use AWS Cloudformation and for GCP Google Cloud Deployment manager. A business reason is often that the engi…

As a software engineer, Terraform/HCL being a real declarative programming language is a big advantage of the big ball of JSON/YAML from cloudformation.

Re: Creating my personal cloud with HashiCorp

#45
post #5

As a DevOps guy, I'm not a huge fan of Terraform. Often I hear from enterprises that Terraform is cloud agnostic, but that's often very wrong. Terraform modules are still specific to the cloud platform and a rewrite is required to port an app running on AWS to GCP. If you use AWS, you're probably better off to use AWS Cloudformation and for GCP Google Cloud Deployment manager. A business reason is often that the engi…

You’re entitled to your opinion, but I want to point out that learning N different custom infra as code systems for N clouds is not really sustainable. If you’re mostly using just one cloud, it makes more sense. Terraform is cloud agnostic in that once you build a process around it… CI/CD of Infra as Code, runbooks around how to work with failures, break glass etc, you can basically use the same thing for any cloud, since all of them have terraform “providers”.

Also all the major clouds (even the minor ones) have pretty strong first class support for terraform.

Re: Creating my personal cloud with HashiCorp

#46
I was in a similar situation a few months ago. I had previous positive experience with k8s and some negative experience with nomad, so I was torn between k3s/k0s and just docker stack+swarm. I didn't want to install anything as I started with a minuscole node (5$ digital ocean node).

In the end I went with docker stack + machine + swarm + docker flow proxy and it's been pretty smooth sailing.

I don't need anything else installed on the machine, I can develop stacks locally with docker compose, deploy them to swarm and I can even add replication on multiple machines for services that need it. I manage secrets with stackoverflow's blackbox and the secrets live in the repository encrypted. I can easily run commands on the local or remote stack via docker machine. I cheated with cron jobs and I just synchronise /etc/cron on all hosts with a directory in my repo. The commands are mostly running commands inside containers.

I have one stack for redis, postgres, docker registry and multiple stacks for other applications. The flow to deploying stuff is basically: generate id from git hash, build docker image, push to self hosted registry, stack deploy with the git hash as version.

A few caveats I found:

- Dependencies with docker health checks will take the duration of the health checks to become available to services needing them. Either you skip health checks or setup things so that infra is running before your services.

- In order to use docker-machine on multiple machines / with different contributors you need to export the key used to setup the machine and export it (there is a npm package that works very well, but it would be nice to have it natively).

- You have to cleanup the docker registry manually every once and then (I had to write a cron job for that)

- I'm unsure about the future of docker, albeit things work pretty well as they are.

Re: Creating my personal cloud with HashiCorp

#48
post #5

As a DevOps guy, I'm not a huge fan of Terraform. Often I hear from enterprises that Terraform is cloud agnostic, but that's often very wrong. Terraform modules are still specific to the cloud platform and a rewrite is required to port an app running on AWS to GCP. If you use AWS, you're probably better off to use AWS Cloudformation and for GCP Google Cloud Deployment manager. A business reason is often that the engi…

What do people here think about Pulumi?

I like the concept of using different languages instead of terraform because I consider the latter to provide pretty terrible developer experience.

I don't like the idea of having a Turing complete language to do that. I would prefer things to be declarative. Honestly I would just be happy with a better terraform without yaml and better tooling for terraform.

I tried to use pulumi and they didn't support something I needed, or maybe I was too dumb to understand how to do it, so I insta quit.

They're also pretty pushy in selling whatever they're selling.

Re: Creating my personal cloud with HashiCorp

#49
post #12

Earlier quoted context omitted.

I'm not the biggest fan of Terraform either but it would be naive to deny that Terraform doesn't still offer a lot of advantages over CloudFormation even if you're not writing cloud agnostic code (even though I do actually agree with your point that Terraform doesn't make your infra cloud agnostic). Terraform offers far more constructs than CloudFormation and there is still a lot to be said for using the same languag…

I agree with this. Terraform is definitely the least-bad tool, especially in that it integrates with so many more services than CloudFormation and has far fewer bizarre limitations than CloudFormation (e.g., you cannot pass objects in CF, and arrays can only be simulated as comma separated strings). Terraform isn’t great, but CF is awful, and even the AWS folks will point you at the CDK instead.

Agree CF is crap.

Each clouds SDK in the language the team is most familiar with is by far the best option.

State can be stored in git. Any version of my infrastructure is a git checkout away.

I use Go, and the documentation for the AWS SDK includes copy-paste examples

Try and checkout Terraform from 6 months ago and run it? Frequently I cannot even get someone’s tutorial example written a week prior to work without edits.

I checked out a year old commit in my infra repo; rebuilt an entire ECS stack deprecated 18 months ago.

Just be programmers. The cloud ops scene is just reselling the same delusions as Unix grey beards and Windows server admins. It’s about making hardware do the right thing, not hand wavy semantics.

Most of the people I work with just regurgitate memes. Very few actually test them for truth.

Re: Creating my personal cloud with HashiCorp

#50
post #13

Earlier quoted context omitted.

For one, it's closer to a proper programming language as opposed to straight up data interchange format. Sure if you write it in YAML than you can take advantage of variables but YAML's syntax for variables is pretty gross. Comparing CloudFormation to Terraform is a little like comparing HTML and CSS to Javascript (though Terraform isn't nearly as nice to code in as Javascript -- and I'm not exactly a big fan of Java…

Out of interest, do you find yourself writing actual software with CDK stacks integrated, or is it more accurate to say the CDK is just a stand-alone bit of code purely for deploying infrastructure? I'm definitely in the latter camp, which is something I find frustrating. I get that for a developer the syntax familiarity might make CDK easier, but for me as a non-developer the pain of groping around the terrible docu…

I strongly suspect that these CDKs are not very well designed. In particular, what I want is something that lets me generate YAML/etc in a type-safe fashion. That YAML is then the input for an engine which reconciles the desired state with the actual state (a la Terraform or cloudFormation). The idea is that the “real programming language” layer just allows us to DRY our YAML. For a use case like this, we don’t need inheritance or methods, but just structs, maps, arrays, and functions; however, these CDKs typically index pretty hard on inheritance and generally make things more complicated than necessary.
Post reply on HN