Release Notes

1.1.1.1.3. Provisioning Containers

Container Provisioning

With previous versions of fraXses it was always difficult to gain access to a consistent environment in which to install. There were always security and access issues that hampered the install process. Additionally, there was always the spectre of quirks of the environment getting in the way – i.e. Ansible port disconnection being blocked (don’t ask!).

For that reason, among others, the Platform Development team decided to leverage containers to provide a consistent and reliable environment from which to provision.

Implementation of fraXses is via a number of provisioning containers:

  1. kube (Kubernetes on-prem implementation)
  2. core (fraXses Data fabric)
  3. app (fraXses App fabric)

Running the containers

Each container can be run wherever Docker can run. This process requires the container to be run interactively from the command line to execute into the container.

docker run -it --rm -v "$(pwd):/provision" -w "/provision" registry.fraxses.com/deployment/core:0.1.18 /bin/bash

There is quite a bit to digest here so we will take each argument in turn. We will ignore docker run as it should be obvious what this is doing.

Running interactively

-it means that the container will be run in the foreground of the terminal rather than as a background process.

Removing terminated containers

--rm means that as soon as the terminal process is exited, the container will be terminated so as not to leave unnecessary containers running on the host machine.

Mounting a local volume

This is important. One of the most important things in the implementation process is to keep a record of the implementation files – playbook, kube config, kube yamls etc. These files exist only in the provisioning container unless you mount a local volume on the host machine which can be used to keep the files after the container is terminated. The -v flag indicates that a volume should be mounted. The next argument is the mapping “host path:container path“. "$(pwd):/provision" states that the current working directory on the host should be mapped into the provision directory in the container. The container path name doesn’t really matter as if it doesn’t exist it will be created. $(pwd) is something to be careful of, it will change depending on the host OS and terminal that is being used. For example, in Windows Powershell, it needs to be in capital letters $(PWD).

PLEASE USE DIFFERENT HOST FOLDERS FOR DIFFERENT PROVISIONING CONTAINERS

Working directory

-w just defines the working directory in which to execute into when the container comes up. For convenience it should be the same container path that was defined in the previous step.

Image

The next argument is the image that needs to be run. All the provisioning containers are on the same path registry.fraxses.com/deployment. The next part of the path is the name of the provisioning container that is being run and a corresponding version. When is comes to provisioning on a client environment, the names and versions will be those stated in the release notes.

Command to execute

The final argument is the command to execute inside the container. This is always a bash environment in order to get command line access to the container.

Getting the playbook

Once you have executed inside the container you will need to copy the playbook files from their image location to the location that you have mounted. The playbook and any associate files exist in the /home/fraxses/deploy path. These files will need to be copied from that location into the location that was mounted in the docker run command. For example, if my volume mounting was:

$(pwd):/mygreatprvisioningfolder

Then you will need to copy into that folder. Assuming you had navigated to that folder in the container you could run:

cp -rf /home/fraxses/deploy .

Tools

The Platform Development team have packaged inside the container the tools that we think are most useful. These tools include:

  • kubectl (most important)
  • bash
  • zsh
  • dos2unix (for converting windows file endings)
  • sudo
  • zip
  • unzip
  • git
  • wget
  • vim
  • neovim
  • tmux
  • curl
  • openssl
  • python2
  • python3
  • nodejs
  • yarn
  • yaml-language-server

Whilst this list is fairly comprehensive, if there are other command line tools that you are more adept at or prefer then please reach out to the platform team as we would be happy to include so long as the tool doesn’t bloat the image.

We are using cookies to give you the best experience on our site. To find out more see our Cookies Policy.  By continuing to use our website without changing the settings, you are agreeing to our use of cookies.