Divio Cloud overview¶

The Divio Cloud is a Docker-based platform-as-a-service. SeeDocker basics for an introduction to Docker and its key components.

The Divio Cloud offers a local development environment that replicates almostperfectly the Cloud environments in which applications run, eliminating many ofthe pain-points of deployment caused by having to deal with differentenvironments in development and production.

In our architecture, we abstract functionality from configuration so thatfunctional components can be made immutable and stateless wherever possible.This enables them to be replaced, added, moved and so on simply by spinning upnew instances, without requiring manual configuration.

Divio Cloud infrastructure¶

Our Cloud is built on a Python/Django stack. Our client sites run in Dockercontainers. More information about our infrastructure can be provided onrequest.

Divio Cloud projects¶

The three environments¶

Each Divio Cloud project includes three environments, each of which will createa version of the website.

The three environments are created in Docker containers from the same images.

• Local, running on your own computer
• Test, running on our Cloud servers
• Live, running on our Cloud servers
  In our workflow, development is done locally, before being deployed to Test_and finally to _Live.

Project site stack¶

The stack running Cloud sites is:

Container

Docker

Operating system

Ubuntu Linux

Web server/web application gateway

Divio loadbalancer plus uWSGI (local sites use the Django runserver.)

Database

Postgres (Test and Live sites use an AWS database; Local sites use adatabase running in another local container.)

Applications

Python/Django

Boilerplates¶

Divio Cloud projects represent web projects. Each project requires a frontend,however minimal - at the very least, a basic base.html template. In orderto make Divio Cloud projects immediately useful, they each come with frontendfiles included. These are defined by the site’s Boilerplate, a set of default templates and static file.

Typically, a Boilerplate will define how the Django templates are structured andmake opinionated choices about what JavaScript frameworks and CSS tools areused.

Various Boilerplates are provided as defaults, but it’s also possible to defineand reuse your own.

Our simplest Boilerplates provide only basic HTML and CSS, but moresophisticated ones include advanced frontend tooling: NPM, webpack, Sass andother components.

Project repository branches¶

By default, each project’s code is in its develop branch. This is thenpushed our Git server, where it can be deployed to the Test or Live servers(our strongly -recommended workflow is always to deploy to Test first),

However, on request different branches can be set for the Test and Live servers - for example, develop and master respectively.

In this workflow you would work on develop before manually merging intomaster, and then deploying Live.

Deployment¶

A number of optimisations have been built into our Cloud deployment process tomake deployments faster and more reliable.

Python packaging¶

We maintain our own Python Package Index, with which has pre-builtplatform-specific wheels for all Python packages.

Docker layer caching¶

We don’t use Docker-level layer caching, as certain cases can produceunexpected results:

• Unpinned installation commands might install cached versions of software,even where the user expects a newer version.
• Commands such as apt-get upgrade in a Dockerfile could similarlyfail to pick up new changes.
• Our clustered setup means that builds take place on different hosts. AsDocker layer caching is local to each host, this could mean that subsequentbuilds use different versions, depending on what is in each host’s cache.

原文: http://docs.divio.com/en/latest/background/divio-cloud-overview.html