Geodesic is a “toolbox” distributed as a docker image containing all essential DevOps tools. It's how we get your team up and running quickly.
In the landscape of infrastructure, there are dozens of open source tools that we need on our personal machines to do our jobs. In SweetOps, instead of having you install each tool individually, we use Docker to package all of these tools into one convenient image that you can use as your infrastructure automation toolbox. We call it Geodesic and we use it as our DevOps automation shell and as the base Docker image for all of our DevOps tooling.
Geodesic is just a “toolbox” distributed as a docker image. Think of it as a DevOps Linux Distribution packaged as a Docker image that provides users the ability to utilize atmos,
helmfile, the AWS CLI, and many other popular tools that compromise the SweetOps methodology without having to invoke a dozen
install commands to get started. It’s intended to be used as an interactive cloud automation shell, a base image, or in CI/CD workflows to ensure that all systems are running the same set of versioned, easily accessible tools.
These days, the typical software application is distributed as a docker image and run as a container. Why should infrastructure be any different? Since everything we write is “Infrastructure as Code”, we believe that it should be treated the same way. This is the “Geodesic Way”. Use containers instead of awkward “env managers” (e.g.
tfenv), complicated folder structures, and symlink hacks. Geodesic is the container for all your infrastructure automation needs that enables you to truly achieve SweetOps.
An organization may choose to leverage all of these components or just the parts that make their life easier. We recommend starting by using geodesic as a Docker base image (e.g.
FROM cloudposse/geodesic:... pinned to a release and base OS) in your projects.
Before there was geodesic, the common ways to manage these tools were:
- Install two dozen commands locally using Homebrew.
Protip: use a
Brewfileto define all dependencies and commit this to the infrastructure VCS.
- Use a virtual machine that has all the tools you depend on. This was pretty typical before the advent of Docker (and let's face it, docker on Mac runs in a VM anyways).
- Use ansible to run some playbooks to configure the host machine (e.g. your laptop)
- Use a
depstarget that installs the tools you need