BitOps is an open source Docker image created by Bitovi that bundles popular deployment tools with the understanding of what to do with an operations repository. This coupling makes it easier than ever to set up the automated deployment of cloud infrastructure. However, BitOps requires an operations repository to work its magic.
This is part 2 of a BitOps tutorial series:
An operations repo is a repository that defines the intended state of your cloud infrastructure. It follows an opinionated structure to allow BitOps to traverse the repo.
To introduce users to operations repositories, we’ve created a yeoman package that makes it easy to get started with BitOps. Just run
npm install -g yo npm install -g @bitovi/generator-bitops yo @bitovi/bitops
yo @bitovi/bitops and Yeoman will create an operations repo for you based on your inputs.
The generator will ask you for an environment name and what deployment tools you want to use.
- Terraform for provisioning of cloud infrastructure
- CloudFormation for provisioning of AWS infrastructure
- Ansible for the configuration of cloud infrastructure
- Helm for deploying to kubernetes clusters
We recommend Terraform and/or Ansible for your first time.
The yo generated
README.md will contain a docker run command for running BitOps against your new operations repo. Cool!
docker run \ -e ENVIRONMENT="backend-test" \ -e AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID \ -e AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY \ -e AWS_DEFAULT_REGION="us-east-2" \ -v $(pwd):/opt/bitops_deployment \ bitovi/bitops:latest
After creating an operations repo, running BitOps with the docker run command above will scan the operations repo’s
backend-test directory for supported deployment tools and run those tools using executables bundled in the image.
The Terraform and Ansible code generated by running the yo command will not actually create any infrastructure so they’re totally safe to run. Cloudformation and Helm scaffolding will create infrastructure or require existing infrastructure so they’ll be reserved for a future post.
Already have an operations repo/IAC?
If you already have an operations repository or a repository containing infrastructure as code, you can still use
yo @bitovi/bitops to help.
Suppose you have a repository containing a JS application in an
app/ directory and Terraform code in an
This is actually an anti-pattern. Infrastructure code should reside in a separate repository from your application code because application artifact lifecycles and versioning tend to follow a different timeline than the infrastructure they're deployed onto. A new repository should be created and infrastructure code moved into it.
From the root of your application repository run
mv ../$APP_REPO/infrastructure/my-terraform.tf infrastructure/terraform/
yo @bitovi/bitops and moving your existing infrastructure code into the generated
infrastructure/terraform/ directory will give you a BitOps compliant operations repository structure!
- Application tests
- Application build
- Artifact publishing
- Infrastructure creation
- Artifact deployment
The pattern of creating a new operations repository environment with
yo @bitovi/bitops, moving existing infrastructure code into it, and updating pipelines can be done regardless of your current state.
By running the command
yo @bitovi/bitops, you’ve set up an operations repo and then deployed its contents to the cloud without installing any other tools. Want to learn more about using BitOps? Check out our github, our official docs or come hang out with us on Slack!