This Tutorial walks through the process of using the Reflex Engine demo setup with Launch Assist to run a container.
You should already have an understanding of Docker before proceeding.
- You have a docker service running. This can be a standalone server, or a managed service of some sort. For the purpose of the example, I will refer to using
Docker Cloud(Free controller for one node).
- You have docker installed locally as well (Mac or Linux).
- You have tried the Test Drive
The steps of this tutorial are:
Setup Reflex Tools
These steps are described in the Reflex Tools section.
Setup Reflex Engine
- Create a MariaDB database service. Identify the db server name, database name, and the user/password with DDL rights.
- Create configuration for Reflex Engine. Example below (You can use any arguments available to the MySQL connector):
- Define your Reflex Engine service. In Docker cloud you could create a stack using the following configuration:
- Deploy the engine and verify it connects to its database and can communicate on its service port (54000).
- Optionally: setup SSL in front of Reflex Engine (with a load balancer or nginx). For production it is strongly urged to run this behind an SSL service.
- Identify the
REFLEX_URL, which will be the service address, port, and
- Use reflex tools to set your REFLEX_URL/APIKEY and then populate Reflex Engine with demo data:
Build the Service
Step-1: Create a docker hello-world
For simplicity we are re-using the docker engine container. Reference Adding Reflex Tools to your Dockerfile for how to do this with your own container.
Create a new container named
bct-tst – this will use the demo service of the same name. For this example we will extend the reflexsc/engine container (because it already has reflex tools as well as the engine). Create a new Dockerfile:
The first thing you may notice is the unique Entrypoint. This is how Reflex works in an Infrastructure as Code polymorphic manner, and the tool is Launch Assist. Instead, we set how the service launches on the Pipeline.
Step-2: Build the container
Standard docker build. Try something like:
Step-3: Setup the bct pipeline
Dockerfile we specified an ENTRYPOINT for Launch Assist. Now we need to define what the containe will actually do. We set the entrypoint on the
bct pipeline with:
This establishes how the container should be run (see the Pipeline for additional info). Notably, we are telling Launch Assist that our “config” directory is the nginx root, and we are telling it how to execute with
exec (similar to
ENTRYPOINT in the dockerfile.
With this approach, when the container is run launch assist calls out to Reflex Engine, gets the launch information above, and executes in that context. Because it is running from within the container, it has an opportunity to lay down configurations and run other commands as desired, while still maintaining the ephemeral nature of the container, as well as security (as you have not had to store your configurations in environment variables, nor within the container image itself).
We tell Launch Assist what service to run through the environment variable
REFLEX_SERVICE, which points to the Reflex Engine Service Object, and that in turn pulls in the Pipeline and any Configuration objects.
You will also notice we used the action
merge. This allows us to make incremental changes. We could also have run
edit and reflex would have brought us into an editor, or
update which would take the complete object from the CLI.
Step-4: Test the configuration
You can test what will happen by running launch assist yourself, with the
config argument instead of
service. You also have the option of including the service on the command line, which will override the environment variable:
It will likely error and fail, as the
--commit argument tells it to write any changes to disk, and your local machine may not refelect the same
cfgdir. You can leave off
--commit and it will just resolve the objects and print the combined result to your screen.
Step-5: Run the container
Now just launch the container. You need to include the three environment variables, even if you have set them locally, because this is telling Docker to let the container use those variables. If running locally try one of the following (the second option is useful when your configurations are stored):
A note on docker networking: The container is likely running on a bridge network, and if your
REFLEX_URL is set to
localhost it will not be able to route appropriately! You will need to set your
REFLEX_URL to something which the bridge network can talk to, such as your external IP address.
For a Docker Cloud stack file, you would need to push
hello-world to your registry and try something like:
When this is run, the logfile may look something like:
Note: the error given is normal for apache under this circumstance.
At this point, you can test if all worked well by using curl to pull the “secret” config file (normally you would never put cfgdir as your public files folder):
And the resulting output should look like the db section of your configuration, which Launch Assist extracted from Reflex Engine (where it was stored encrypted) and then saved to the local container:
Note: there is an option to have Launch Assist send the configuration directly to STDIN of your process. >todo: future docs<