3 ms·
Key takeaways for me: - __Right now__, Otto appears to be Vagrant++. I wouldn't use this for prod, at least not for a while. - Otto is written in Go. Source i
by throwaway9851 11y ago
Key takeaways for me:
- __Right now__, Otto appears to be Vagrant++. I wouldn't use this for prod, at least not for a while.
- Otto is written in Go. Source is here: https://github.com/hashicorp/otto https://github.com/hashicorp/otto
- Otto uses a plugin model for different applications. Plugins aren't supported yet. https://ottoproject.io/docs/plugins/app.html https://ottoproject.io/docs/plugins/app.html
- Built in plugins don't appear to be consuming a sane plugin interface. How the built-in plugins work is non-obvious.
- Under the hood, Otto appears to be using Packer, Terraform, and Vagrant.
- I would consider Otto, Nomad, and Terraform to all be "provisioner tools". They seem to be all directly related to tools such as Ansible provisioning, Chef provisioning, Fog, or other direct management tooling, like the AWS CLI or Powershell CLI for VMWare.
- Otto, Nomad, and Terraform all promise to solve the same problem in prod in different ways:
-- Otto is a one-off push to set up infrastructure and deploy to prod.
-- Nomad is for pushing jobs to help maintain long standing infrastructure in prod.
-- Terraform is for periodic pushes to prod to create idemopotent infrastructure.
In other words, from least to most robust IMO:
Least Robust -------> Most Robust
Otto --> Terraform --> Nomad
- timdorr 11y agoI think the Terraform/Nomad/Otto hierarchy is supposed to be like this: - Terraform defines that you have X servers with certain specs. - Otto defines that those servers are running Docker or whatever. - Nomad defines that your application is running in X containers in your infrastructure. So, it's a layered approach (Infrastructure -> System -> Application), akin to the layers of your network. Each one is isolated enough to not worry about the others. At least, that's how I'm hoping this all shakes out :)