Continuous Delivery Use Case

A company is currently using Agile for SDLC. Every time there is a production release, they upgrade the servers. However, they want to start using the immutable infrastructure pattern, as they want the whole delivery chain to be more resilient, flexible and portable with better safeguards.

Immutable Infrastructure in a nutshell

  • The immutable infrastructures pattern divides the infrastructure into two areas: data and everything else. The "everything else" components are replaced at every deployment, rather than being updated in-place.
  • You should never change any part of the production once it is deployed. If you need a new change, deploy a new system.
  • It is best to automate everything at the lowest level possible.

Application Architecture

Their example application and the system configuration management codes are publicly available in github.

The server architecture contains three roles:

ManageaCloud needs to understand how to configure those roles. You do this by creating the following server configurations:

The individual server configurations build successfully. Now we can create the macfile that will define the relationship between those roles.

Macfile the blueprint architecture file

When using the immutable infrastructure pattern we have to divide the data and everything else. Therefore, we will have two macfiles, one for the database and another for the rest of the application.

In this example, we do not need to re-create the database server every time we deploy a new infrastructure.

Database macfile data

The database infrastructure macfile creates a production database.

mac: 0.7.1
description: Database
name: demo_database
version: {INF_VERSION}

roles:
  db:
    instance create:
      configuration: demo_database

infrastructures:
  db:
    name: 'db'
    location: us-central1-c
    deployment: production
    hardware: https://www.googleapis.com/compute/v1/projects/manageacloud-instances/zones/us-central1-f/machineTypes/f1-micro
    role: db

To orchestrate a new production database server, we can use the mac command line interface. We save the contents in a file, for example, called demo.database.macfile, and execute the following command:

mac infrastructure macfile demo.database.macfile  -p INF_VERSION=1.0

We need the private ip for the next infrastructure file:

mac instance ssh <instance_id or name> -c ifconfig

Infrastructure macfile everything else

This infrastructure macfile defines everything that is not data. In this case, it is the load balancer and the application server. Every time we are make an upgrade that is not data, we will be creating a new INF_VERSION of this infrastructure.

mac: 0.7.1
description: Infrastructure demo
name: demo
version: {INF_VERSION}

roles:
  lb:
    instance create:
      configuration: demo_loadbalancer
      environment:
      - APP_IP: app.PRIVATE_IP
  app:
    instance create:
      configuration: demo_application
      environment:
      - DB_IP: {DATABASE_IP}

infrastructures:
  app:
    name: 'app'
    location: us-central1-c
    deployment: production
    hardware: https://www.googleapis.com/compute/v1/projects/manageacloud-instances/zones/us-central1-f/machineTypes/f1-micro
    role: app
  lb:
    name: 'lb'
    location: us-central1-c
    deployment: production
    hardware: https://www.googleapis.com/compute/v1/projects/manageacloud-instances/zones/us-central1-f/machineTypes/f1-micro
    role: lb

To orchestrate a new production database server, we can use the mac command line interface. We save the contents in a file, for example, called demo.architecture.macfile, and execute the following command:

mac infrastructure macfile demo.architecture.macfile  -p INF_VERSION=1.0 DATABASE_IP=10.240.232.234

Please note that DATABASE_IP is the private ip of the database that was orchestrated in the previous step as per immutable infrastructures.

Benefits

  • Immutable infrastructure creates a production-ready brand new infrastructure every time we want to modify the production environment.
  • The system allows for testing of the production environment before activation.
  • If any problems arise, rollback is simple as the previous production infrastructure is still available.
  • If there is a production problem in the active production infrastructure, you can create another production infrastructure to replicate the problem and work in a solution without disturbing your users.
  • The change management is simplified: servers never rot, you can think of an application as a single deployable artefact and reason about it at a higher level.
  • Users gain an increased understanding about of the whole delivery chain, making it more resilient, flexible, portable and with better safeguards.

Want to know more ?

If you'd like to know how ManageaCloud can help you with Continuous Delivery, please get in touch. We'd be delighted to hear from you.