Docker Enterprise Architecture¶

If you are engaged in Docker at an enterprise scale level, you are certainly facing challenges like:

how to build a robust and secure docker infrastructure ?
how to deal with docker containers lifecycle ?
how to implement segregated environments (production, development, integration, user acceptance tests, ...) ?

OpenSVC propose a ready to use model to integrate docker in your company, as described in the picture below

_images/docker.enterprise.architecture.png

Description¶

This architecture is composed of 3 stages:

Production on the left
User Acceptance Tests in the middle
Development on the right

Each stage has:

a dedicated pool of physical nodes to host OpenSVC services running Docker
a dedicated docker private registry hub, storing the accurate docker images
a set of OpenSVC services, embedding one or more docker containers, rendering mass docker container management very powerful

Step 1¶

First users in the docker infrastructure is the technical people involved in building new environments
They have their own docker setup on their laptop, pull images from public docker hub registry, modify them, and push them on the Dev private docker hub, which is an OpenSVC service named dev/dckhub

Step 2¶

Development teams are responsible of deploying docker containers, exactly like they are executed on production infrastructure.
They work with clones of the production OpenSVC services. The service names or namespaces differ (dev/app1 vs prd/app1).
They can push/pull from/to the dckhub.dev private hub, and adjust their development/integration to meet application expectations.

Step 3¶

Application responsibles (called Release Manager) decide when an application is ready for user acceptance tests.
They pull the docker images from the dev/dckhub private Dev hub, and push them to the tst/dckhub test hub.

Step 4¶

Teams in charge of running test plans start testing on the new application just published by the Release Manager
They change the image tags in OpenSVC services tst/app* and restart the services (or re-deploy), then execute the test plans.
If tests pass, images can go to production. If not, back to step 1.

Step 5¶

Application responsibles (called Production Release Manager) decide when an application can go to production.
They pull the docker images from the tst/dckhub private test hub, and push them to the prd/dckhub production hub.

Step 6¶

Operation/Production teams are responsible of running applications in production.
They configure OpenSVC services (prs/app1, prd/app2) to use the new docker image tags, plan downtime, and restart services.

OpenSVC collector useful sysbsystems¶

The OpenSVC collector (optional in the architecture) can provide:

Service configuration compliance
- compliance rules are declared in the collector, and served to every OpenSVC agent
- on schedule (once a week, once a day, ...), OpenSVC agents check the rules and report

For example, you could setup this contextual ruleset:
+- it.applications.app1 (contextual ruleset, shown to all app1 OpenSVC services)
   |
   +- it.applications.app1.dev (contextual ruleset, matching app1 **Dev** OpenSVC services)
   |  |
   |  +- container#1.image_id = 1111122222 (docker image id to be used to instantiate container)
   |  `- container#2.image_id = 2222211111
   |
   +- it.applications.app1.tst (contextual ruleset, matching app1 **Tst** OpenSVC services)
   |  |
   |  +- container#1.image_id = 3333344444
   |  `- container#2.image_id = 4444433333
   |
   `- it.applications.app1.prd (contextual ruleset, matching app1 **Prd** OpenSVC services)
      |
      +- container#1.image_id = 5555566666
      `- container#2.image_id = 6666655555
With this ruleset, you can very easily ensure that no change happen on your infrastructure: your docker containers stacked together, and managed through OpenSVC services will remain predictive, in 2 weeks, in 2 months, as long as compliance jobs are not reporting errors, you are sure the services are still setup the way they were deployed.

Up-to-date inventory of in-use docker images, indexed by service, environment, node, application. This capabilty enables infrastructure billing and security risk assessment very easy.
Web based OpenSVC services management
- can be segregated to allow dev people to access dev services only, etc
- in compliance subsystem, remediation campains can be scheduled and triggered from the web interface