1: Overview of development using Audienti

In ongoing development, we use Docker for our development environment. This requires a 1 time setup using the Audienti repo (improvements are always welcome!).

The CLI that is used as part of the tool is the big thing to understand. There are a few key things it does.

• Sets up your ENV to match what's expected by other scripts (by typing cli config)

• Builds images and pushes them to dockerhub (cli build oma-processors)

• Builds the rancher-compose and docker-compose files using templates to push to Rancher (cli write_rancher_stacks docker dc1)

• Automates a rancher deploy of all microservices, or individual microservices (cli deploy_allorcli deploy opportunity-pipeline)

Docker-based development

One big thing the setup above does, is setup your environment with shortcuts that help you with development. Specifically, there are commands that are used EXTENSIVELY for development. They are called "dcdx commands".

DCDX commands are built with the following syntax:

• dc = docker compose

• x = your target environment (development = d, staging = s, production = p, production_local = pl, test = t)

• r = your command (r = run, b = bash with mapped service-ports for running a web server and doing development)

You use these commands like this:

• dcdr oma bash --login= login to the oma container at a bash prompt, run the login script for bash to give you a nicer prompt that shows your github branch etc.

• dcplr oma bash --login= login to the oma container at a bash prompt, run the long script, in the production_local enviornment. Service ports will NOT be mapped.

• dcplb oma= login to the oma repo container in production_local mode. Map the port 3000 to the host, so you can run the web server and see local changes, connect to the production databases.

How your docker-compose.override.yml works

When you build a container, it builds a production version of it. This will copy the code at it current state, and generate a docker image that matches it. This image is immutable (not changing). Every time you boot it, it will be the same image in the exact same state.

So, for development, we use a docker-compose.override.yml, this will essentially "map" into the production image the local folders you have on your site. It also has definitions for you postgres, elasticsearch, redis, and other databases so that you have a local copy of them in the same "network" as your app container.

If you don't have the docker-compose.override.yml, then you won't be able to connect to development databases.

Run versus CMD versus bash.

When you run a docker image with the run command (our default way to get a bash prompt), you will NOT map the service-ports, which means your ports (like port 3000 for web development) will not be exposed to the host. This is good, because you can have 2 or 3 command lines running at the same time.

If you need to get service-ports mapped, you must run it with the --service-ports flag. As indcplr --service-ports oma bash --loginto get the service-ports mapped.

When you use thedcplb omacommand, that is all this is doing. It's a run command with service ports mapped automatically.

How image building works

When you build a new image, by launching it and one doesn't exist, or by typing the commandcli build oma-processors, the command will rename your docker-compose.overrride.yml to remove the mapping before the image is built. If you build an image and try to launch it that is built with the override file in place, it will error.