Skip to content

Configuration

David Sanabria edited this page Aug 6, 2020 · 1 revision

CWDS Configuration

CWDS Configuration focuses on the infrastructure, software, and services that support the Child Welfare Digital Services application and administration functions. We use a combination of Ansible and Amazon CloudFormation to configure, deploy, and manage our environments. This page describes our environments and packages.

Contents


Environments (top)

The DevOps Engineering team divides infrastructure up into environments. An environment is an isolated network that contains all of the internal servers, services, security, and connectivity (packages) to produce an externally cohesive service. An example is the INT01 - Intake Integration environment, which is the integration phase application environment. There is a lot of information packed into this designation, and some information that is not immediately visible

Environment Classes

There are four environment classes that we currently support: Application, Management, Training, and Web. Each class is a template that we use to spin up new environments focused on a particular problem space. Our goal is to keep the number of classes or templates to a minimum, and use infrastructure code broken down into packages, which allow modular reuse across environment classes.

  • Application — Application environments are load-balanced and configured with auto-scaling. There will be many of these types of environments to allow for multiple, concurrent development streams for each digital service.
  • Management — Other environments are organized in a hub-spoke model, around a single management environment. A management environment is a control point as well as a central hub for command and control.
  • Training — Training environments are similar to application environments, but have a data tier that is refreshed nightly. As there is no need to preserve data, these environments use containerized databases that are redeployed often, as needed, to reset the data available to a given environment.
  • Web — Web environments are also similar to application environments, but are organized for access by the general public. They are isolated from application environments to provide an additional layer of security for application data.

Each environment class has it's own Cocina, Spanish for "kitchen", where the environment class is designed and changes are tested before pushing them out to a new or existing environment.

Additional Information:

  • Environments are managed using Ansible, in a single code branch that is stored in GitHub.
  • Variables files are encrypted with Ansible Vault

Environment Phases

Environments are created for a specific phases of the class life cycle. CWDS Currently only builds and supports non-development phases, as defined in list below. Environments are identified by a short code that combines the environment phase with a sequential number that is unique with the phase. For example, the first integration environment that we built was given the code "INT01". This short code makes for easy reference, and when combined with the title, makes for an easy-to-remember identifier like "INT01 - Intake".

Application Phases:

  • INT — Integration. An Integration environment is used to test API code with GUI code, which is typically developed by two different teams. Integration environments often have many deploys in a short period of time, and often small databases intended for basic functional and integration testing by development teams as well as project staff. They are also used to display the latest versions of code and live, non-prod databases.
  • SYS — System Test. System Test environments are used to deploy API and GUI code from two or more teams, which allows for testing of system functionality as well as the stability of components working together in the same environment. These environments can also be called "QA" environments because they are the first point at which all application components are brought together and access live, non-prod data from multiple sources (e.g. CWS legacy data and CALS facility data).
  • PERF — Performance. There is only one performance environment (currently). This environment is used to measure application performance against a full copy of the production databases used in PROD.
  • PROD — Production. Production environments are intended to be essentially read-only, high security environments where the entire environment is deployed at one time using the latest stable version of each component.
  • TRN — Training. A Training environment is similar to a SYS environment, except all data is kept in databases that are easily reset when needed. These databases will typically be kept in Docker containers and deployed as needed, when data needs to be reset or new training scenarios are added.

Docker Containers

Docker containers are used to bundle application components and their dependencies in a tested package that is easy to deploy. They are reserved for use by stateless components, or stateful (data) components that need to be reset often to a baseline state.

Clone this wiki locally