This project will be a multi-part series demonstrating a best practices approach at developing and deploying an infrastructure with code.
Everything in Code
No server or other system should have local modifications, while you may need to log-in for inspection purposes, you should not be modifying config files or code in any fashion directly on the servers.
All systems including development systems must be maintainable and we must have the ability to recreate systems at any time, and in (almost) any place.
Each piece should be considered for it's modularity. If it can be reused, reuse it.
Along with modularity, is ensuring those modules are as independent as possible. Technology changes so rapidly today, that tomorrow your investment in a particular stack may be obsolete. By limiting the coupling between these technologies we can swap them out more easily if the situation arises.
Minimize external dependencies on external projects and infrastructure
Controlling dependencies is one of the hardest tasks in any large scale software project. While you should strive to not fall into the NIH or Not Invented Here syndrome you will also realize that:
If you are dependent on another party for anything, at some point that party WILL fail!
Though not frequent anymore, github.com has been known to go offline, docker images sometimes break from dockerhub, and software libraries mysteriously disappear. Any one of these and many other circumstances beyond your control can break your build and infrastructure, so we will strive to remove these dependancies as much as possible.
Tools utilized in the current rendition
Because of course. If you're new to Docker, the use-case I present here may be the defining factor to get you to use it for real. Docker and Linux containers in general can be thought of as many different things to different people, and the simple Hello World exercises do not fully explain their power. We will use Docker images here simply as a set of artifacts that move between systems, and house various pieces of functionality. The containers will allow a certain aspect of the train how we fight mentality that is taught by the U.S. Military.
Ansible is a wonderfully simple automation framework. There is no technical reason why you couldn't use salt or puppet, or even shell scripts to automate your infrastructure, but for this project we choose ansible. If you adhear to the Decoupled technologies philosophy you should be able to change out your automation framework, while maintaining a similar platform.
Vagrant will be used as the local development environment and 'master' control node for the entire infrastructure. This means that anyone with a copy of your project can control the infrastructure if you allow it. We will go into detail on how to make this secure, and how to protect your secrets when everything is in source code.
Series Post Schedule:
- Building your Vagrant local control node
- Securing secrets
- Setting up a development tools server
- Creating a private repositories for docker images, binaries, and source artifacts
- Installing the CI/CD server (Jenkins)
- Building your app and it's containers
- Writing the deployment process
- Building and deploying to staging, and production servers
- Testing the infrastructure
- Summary and ongoing maintenance stratagies