knowledge-kitchen

Continuous Deployment - Automatically Launching Applications

Making an application live and available to its users.

1. Overview
2. Moving on from development servers
3. Production environment
4. Cloud deployments
5. Virtual machines and containers
6. Kubernetes
7. Continuous deployment
8. Conclusions

Overview

Definitions

A few terms to disambiguate.

Delivery

• Delivery is placing an app into its target environment and preparing it to be accessed by its end-users, but not actually executing it.

• Continuous delivery is automatically delivering new versions every time a change is made to the underlying code.

Deployment

• Deployment is placing an app into its target environment, executing it, and making it available to its end-users.

• Continuous deployment is automatically deploying new versions every time a change is made to the underlying code.

Caveats

New releases of software, of course, must still successfully build and pass unit, integration and system tests before deployment.

• Thus, Continuous Deployment is a follow-up to Continuous Integration, where tests are automatically run and re-run with every code change.

Automation Pipeline

With version control, code linters, large language model-based code assistants, automated provisioning of virtual computing environments, automated builds, and automated testing, continuous deployment is the natural evolution of a fully automated software development and operations (devops) pipeline.

Moving on from development servers

Overview

Many application development frameworks, including Flask and React, come with development servers.

For example:

• the flask run command launches the development server for a Flask-based application

• the npm start command typically launches the development server for a React-based application

These are simple web servers that can be easily run on a development machine for quick debugging and testing. However, they are not intended for use in production environments.

Limitations of a development server

Development servers are not intended for use in production environments. Typically, development servers are…

• single-threaded - meaning they handle requests sequentially, one at a time, potentially leading to long wait times for users when the server is under heavy load

• insecure - they are designed for simplicity for use on personal machines, not with security as a major concern

• unreliable - they are designed to function well for short periods of time, and not tested in environments where they are used as long-running processes

Production servers

Production servers are intended to be better optimized for heavy loads, more secure, and more reliable than development servers.

• Flask-based applications often use Gunicorn as a production server.

• React-based applications often use Nginx or Apache, or both as a production server.

Product servers (continued)

Tutorials are readily available to give guidance to the process of publishing apps to production servers.

For example…

Using Digital Ocean’s Droplets:

• Deploying a Flask app to a Digital Ocean Droplet
• Deploying a React app to a Digital Ocean Droplet

Using Digital Ocean’s App Platform:

• Deploying a Flask app to Digital Ocean’s App Platform
• Deploying a React app to Digital Ocean’s App Platform

Production environment

Hosting tiers

There are several tiers of hosting available for apps that can be deployed and accessed over the Internet, with many companies and services catering to each type

• Shared hosting
• Dedicated machines
• Virtual Private Servers (VPS)
• Cloud services

Hosting tiers (continued)

Shared hosting

With shared hosting, a developer receives an account on a web server shared by hundreds, if not thousands, of other developers.

• Historically the cheapest form of hosting.
• If one developer consumes more resources than expected, other developers may feel the effects… the “noisy neighbor” problem.
• Has restrictions on what is allowed to be done from a user account… no admin rights.
• No choice of hardware… limited choice of software.

Universities and other large organizations often provide shared hosting for their community members.

Dedicated machine

With a dedicated machine, i.e. a bare metal server, developers buy or rent a single physical machine managed by either themselves or the hosting company from whom it is rented.

• A dedicated physical machine… no virtualization… no neighbors.
• Admin rights to do whatever you want with it.
• Software and hardware management services usually offered at additional cost.
• Resources limited by the physical machine.

Virtual Private Servers (VPS)

With VPS, a developer receives a virtual machine running on a physical machine shared by hundreds, if not thousands, of other users.

• A step up from shared hosting, giving more control and better isolation.
• Each virtual machine runs in an isolated, sandboxed environment, so one account is unaffected by resourcee usage of another… no “noisy neighbor” problem.
• Developers have discretion to do whatever they want in their virtual machine.
• Choice of emulated hardware and software.
• Resources limited by the physical machine upon which virtual machine is running.

Cloud deployments

Deploying to “the cloud” is a catch-all term for deploying to a remote server that is managed by a third party.

Cloud deployments (continued)

Cloud deployments

Cloud services

“The cloud” is usually used to mean a grid of hundreds or thousands of physical computers all inter-networked and sharing resources, but presented to a developer as a single virtual machine.

• Any one application may run spread across many different physical machines.

Cloud resources

Cloud services providers offer a variety of resources to developers.

• Compute services, i.e. virtual machines and/or containers running app code.
• Databases, i.e. SQL and NoSQL data storage
• Storage, i.e. file system where files are stored
• Networking, i.e. IP addresses, DNS, and other configurations that multiple services for a single app need to communicate with one-another.

In addition to these, there are many accessory services such as load balancing, monitoring, logging, analytics, security, etc.

Big tech

The world of cloud deployment is dominated by a few players:

• Amazon Web Services
• Microsoft Azure
• Google Cloud
• IBM Cloud

Their offerings are generally industrial-strength hosting solutions with obtuse interfaces and extensive capabilities that may be overkill and intimidating for non-specialists.

X-as-a-Service

The cloud is often referred to as a “service”, with a few common levels of service available to [paying] customers:

Image courtesy of Microsoft Azure’s “What is PaaS“.

Infrastructure-as-a-Service (IaaS)

Some services handle much of the setup of a cloud infrastructure (compute resources, storage resources, networking interoperability, etc) without requiring the user to configure all details.

• Amazon Lightsail
• Amazon CloudFormation
• Microsoft Azure
• Google Cloud
• Digital Ocean
• IBM Cloud Foundry
• Linode

From IaaS, developers leverage The Cloud to receive the necessary preconfigured [virtual] hardware and networking abilites upon which to develop.

Platform-as-a-Service (PaaS)

Whereas IaaS provides the pre-set hardware and networking of a cloud deployment, PaaS additional provide the pre-set configuration of dependencies and platforms necessary to deploy a specific type of application.

• Amazon AWS Elastic Beanstalk
• Microsoft Azure Web Apps
• Google App Engine
• Digital Ocean App Platform
• IBM Cloud Foundry
• Salesforce Platform
• Platform.sh
• Dokku

From PaaS, developers receive an environment with platform systems already setup on an appropriate cloud compute and storage inrastructure and they can simply get to work on a specific type of project development.

Considerations when choosing IaaS versus PaaS

A few considerations when deciding whether to go with IaaS or PaaS:

• IaaS is fully customizable, whereas PaaS works best if you closely follow common conventions and patterns.

• IaaS requires more setup and maintenance compared to PaaS, since it is more hands-on and configurable.

• IaaS services will cost less than PaaS for the same basic resources, since there is less abstraction and less automation included.

• As a general rule, IaaS may be more suitable for large, complex, or custom applications. PaaS may be better suited for small, simple, or conventional applications.

Virtual machines and containers

Overview

Cloud compute services are provided as either virtual machines or containers.

• Containers are a more lightweight, portable variation of a virtual machine, where the operating system is not included in the virtual environment.

• Cloud-based virtual machines can run containers, if desired.

• Additionally, some providers offer container services directly, abstracting away the virtual machines so developers don’t have to worry about where the container is being run.

Overview (continued)

• Note that a container contains only the necessary dependencies needed to run an application, and do not contain the full operating system, whereas virtual machines do.

Example

For example, Digital Ocean, provides both virtual machines, which they call Droplets, and container deployments using their App Platform or Kubernetes services.

• A simple and cheap setup would be to launch a single Droplet, clone all necessary code repositories to it from GitHub, and manually launch the subsystems directly on the Droplet. Multiple sub-systems can be run on different ports of the same virtual machine, as necessary. This is an example of simple Infrastructure-as-a-Service.

• A simple setup that betrays a more advanced toolset would be to use the App Platform service to build and launch containers automatically hosting each subsystem of your application. This is an example of Platform-as-a-Service.

• If a more custom container setup is desired, the Kubernetes service allows developers to configure a cluster of virtual machines to run containers. This is an example of Infrastructure-as-a-Service.

Kubernetes

Overview

Kubernetes (a.k.a. k8s) is a container “orchestrator” - it manages the deployment of containers across a cluster of machines.

• a “cluster” is a group of machines in a “cloud” data center that work together to run a single service.

• a “node” is a single machine in a cluster, usually a virtual machine but could be physical.

• a “pod” is a group of one or more containers that run together on a single node, with a single IP address and other shared resources.

Comparison to Docker Compose

Docker Compose, which also orchestrates containers, and kubernetes are designed for different use cases.

• Docker Compose can orchestrate a set of containers all running on the same machine. This is usually fine for small deployments with a limited number of containers.

• For larger deployments, where multiple instances of each container might be needed, or where the containers will not necessarily all be running on the same machine, kubernetes is the orchestrator of choice.

• Kubernetes implementations usually start with at least 3 nodes for redundancy.

Components of a Kubernetes cluster

Components of a Kubernetes cluster (continued)

Each node in a cluster runs a container using a container runtime engine, like Docker or containerd.

• The nodes within a cluster are managed by a “Control Plane” that makes sure applications within the cluster are running with the correct configuration in the desired state.

• Each node in the cluster runs “Kubelet” - software that manages the containers running on that node and communicates with the control plane.

• Developers typically interact with the cluster using the “kubectl” command-line tool to deploy, inspect, and manage cluster resources.

Continuous deployment

Overview

Continuous Deployment (CD) is the process of automatically deploying new versions of a software application to a production environment with every change to the codebase.

• Continuous Deployment usually follows Continuous Integration (CI; automated builds and tests), in what is known as the CI/CD pipeline.

• CD would only take place if the CI tests pass.

• The same tools and processes used for CI can be used for CD. For example, GitHub Actions, Jenkins, Travis CI, and Circle CI all can be used for both CI and CD.

Simple pipeline

A CI/CD pipeline for a simple application, such as one running on a single virtual machine, might involve the following steps:

1. Developer pushes code to a repository (e.g. GitHub, GitLab, Bitbucket, etc.)

2. CI server (e.g. GitHub Actions, Jenkins, Travis CI, Circle CI, etc.) builds and runs tests on the code.

3. If the tests pass, the CI server copies the code to the production environment, e.g. by using the rsync command to copy the code from the build server to the production server.

4. The production server deploys the application by stopping and restarting it.

5. The updated application is now available to users.

Simple containerized pipeline

A similar CI/CD pipeline that runs the application either directly with Docker or using Docker Compose (but not using Kubernetes) might involve the following:

1. Developer pushes code to a repository (e.g. GitHub, GitLab, Bitbucket, etc.)

2. CI server (e.g. GitHub Actions, Jenkins, Travis CI, Circle CI, etc.) builds and runs tests on the code.

3. If the tests pass, the CI server uploads the built Docker image to a container registry such as DockerHub.

4. The CI server deploys a container using the new image to the production environment using docker or docker-compose commands.

5. The updated application is now available to users.

Even simpler containerized pipeline

An even simpler containerized pipeline does not require the developer to develop a Docker image of their own system in order to use containers.

• Digital Ocean’s App Platform and similar services can automatically create a Docker image from a code repository and then automatically instantiate containers from this image and deploy them.

Kubernetes pipeline

Deploying to a Kubernetes cluster follows similar steps:

1. Developer pushes code to a repository (e.g. GitHub, GitLab, Bitbucket, etc.)

2. CI server (e.g. Jenkins, Travis CI, Circle CI, GitHub Actions, etc.) builds and runs tests on the code.

3. If the tests pass, the CI server uploads the built Docker image to a container registry such as DockerHub,’

4. The CI server deploys a kubernetes cluster using the new image using kubectl commands.

5. The updated application is now available to users.

Conclusions

Thank you. Bye.