6 ms·
I've started using terraform and packer since I wrote that post. I'm going to stick with those tools for the time being. Configuration management is solving a p
by _qc3o 10y ago
I've started using terraform and packer since I wrote that post. I'm going to stick with those tools for the time being. Configuration management is solving a problem that no longer exists. Pre-bake your infrastructure and then download the rest at runtime if you can't do it at bake time.
Coupled with docker, hashicorpt vault, and fpm I think the problem of deploying and configuring anything is pretty much solved and the remaining issue is basically how you go about doing orchestration for things like rabbitmq clustering which I don't think any of the existing configuration management tools try to address anyway. You either need to configure the topology ahead of time which kinda defeats the purpose of having a reactive infrastructure or you have to write some kind of custom thing on top of what you are using already which again kinda defeats the purpose since most of these configuration management tools try to be declarative and you often need imperative things to configure something like a rabbitmq cluster.
- bostik 10y agoTerraform is a neat tool. From my limited experience so far, it manages to hide most of the complexity when dealing with EC2 network setup. We haven't tested it with VPC peerings yet, but do expect to see that one in a near future too. I don't quite agree with you about config management being useless, but its role certainly can be reduced. A real life example: database hosts with dedicated high performance volumes, their read replicas, and due to regulatory compliance, always up-to-date off site replicas on physical hardware. Same holds for load balancers, btw. And as for docker, I have mixed feelings. I disagree with quite a few of their design and engineering decisions, let alone with their QA so far. However - I do think that they nailed the basics of the devs' workflow UX. Anyone can write a dockerfile, and the deployment story is pretty well thought out. (I happen to disagree with the registry address being part of image namespace, tbh.) Things start to get a bit iffy when you need to consider exported volumes, and host interaction in general; why can't you declare per-image default export paths on the host configuration? Why is restart policy controlled by arguments to dockerd, instead of metadata inside the built docker image? I know the engineer in us all screams "that's a job for the orchestration engine, stupid!" but the fact that you need to accept and integrate with a lot of external complexity tells me that a lot of questions in this space are still open.