Posts in this category
- Automating Deployments: A New Year and a Plan
- Automating Deployments: Why bother?
- Automating Deployments: Simplistic Deployment with Git and Bash
- Automating Deployments: Building Debian Packages
- Automating Deployments: Debian Packaging for an Example Project
- Automating Deployments: Distributing Debian Packages with Aptly
- Automating Deployments: Installing Packages
- Automating Deployments: 3+ Environments
- Architecture of a Deployment System
- Introducing Go Continuous Delivery
- Technology for automating deployments: the agony of choice
- Automating Deployments: New Website, Community
- Continuous Delivery for Libraries?
- Managing State in a Continuous Delivery Pipeline
- Automating Deployments: Building in the Pipeline
- Automating Deployments: Version Recycling Considered Harmful
- Automating Deployments: Stage 2: Uploading
- Automating Deployments: Installation in the Pipeline
- Automating Deployments: Pipeline Templates in GoCD
- Automatically Deploying Specific Versions
- Story Time: Rollbacks Saved the Day
- Automated Deployments: Unit Testing
- Automating Deployments: Smoke Testing and Rolling Upgrades
- Automating Deployments and Configuration Management
- Ansible: A Primer
- Continuous Delivery and Security
- Continuous Delivery on your Laptop
Sat, 16 Jan 2016
Automating Deployments: Installing Packages
$ apt-get update $ apt-get install package-info
package-info with the package you want to install, if
that deviates from the example used previously).
If the package is of high quality, it takes care of restarting services where necessary, so no additional actions are necessary afterwards.
Coordination with Ansible
If several hosts are needed to provide a service, it can be beneficial to coordinate the update, for example only updating one or two hosts at a time, or doing a small integration test on each after moving on to the next.
A nice tool for doing that is Ansible, an open source IT automation system.
Ansibles starting point is an inventory file, which lists that hosts that Ansible works with, optionally in groups, and how to access them.
It is best practice to have one inventory file for each environment (production, staging, development, load testing etc.) with the same group names, so that you can deploy to a different environment simply by using a different inventory file.
Here is an example for an inventory file with two web servers and a database server:
# production [web] www01.yourorg.com www02.yourorg.com [database] db01.yourorg.com [all:vars] ansible_ssh_user=root
Maybe the staging environment needs only a single web server:
# staging [web] www01.staging.yourorg.com [database] db01.stagingyourorg.com [all:vars] ansible_ssh_user=root
Ansible is organized in modules for separate tasks. Managing Debian packages is done with the apt module:
$ ansible -i staging web -m apt -a 'name=package-info update_cache=yes state=latest'
-i option specifies the path to the inventory file, here
staging. The next argument is the group of hosts (or a single
host, if desired), and
-m apt tells Ansible to use the apt
What comes after the
-a is a module-specific command.
name specifies a Debian package,
forces Ansible to run
apt-get update before installing the latest
state=latest says that that's what we want to
If instead of the latest version we want a specific version,
-a 'name=package-info=0.1 update_cache=yes state=present
force=yes' is the way to go. Without
wouldn't downgrade the module to actually get the desired version.
This uses the ad-hoc mode of Ansible. More sophisticated deployments use playbooks, of which I hope to write more later. Those also allow you to do configuration tasks such as adding repository URLs and GPG keys for package authentication.
I'm writing a book on automating deployments. If this topic interests you, please sign up for the Automating Deployments newsletter. It will keep you informed about automating and continuous deployments. It also helps me to gauge interest in this project, and your feedback can shape the course it takes.