| --- |
| title: "ContainerCLI: A CLI tool for your Docker Application" |
| author: Philipp Zehnder |
| authorURL: "http://twitter.com/philipp10der" |
| authorImageURL: "/img/zehnder.png" |
| --- |
| **<div style={{float: 'left', paddingRight: '40px'}}>6 minutes to read</div>** |
| <br/> |
| |
| In this blog post, we show how we developed a CLI tool to install and manage StreamPipes. |
| In addition, we present a template project that enables you to easily create a CLI tool for your own docker application. |
| All you need is a working docker-compose.yml file. |
| |
| <!--truncate--> |
| |
| StreamPipes has a Microservice architecture and we use Docker and Docker Compose for all of our development, testing, and deployment processes. |
| In the beginning, we developed the CLI only to ease the installation process (e.g. managing multiple versions), but over time we realized that the tool is much more powerful. |
| For example, StreamPipes has multiple developer roles: Some developers are working on the frontend, others on the backend, and some are developing new algorithms and data sinks for StreamPipes. |
| In the figure below, you can see different configurations that are used by different developers. |
| All services are running in docker, except for the ones the developer is currently working on. |
| As a result, we had many different docker-compose.yml files and when we made changes, we had to synchronize them all. |
| |
| <img class="blog-image" style={{maxWidth: '60%'}} src="/img/blog/2018-11-24/roles.png" alt="Three different developer roles"/> |
| |
| Therefore, our goal was to speed up the setup of a development environment, so that developers can focus on their specific programming task. |
| That’s why we developed a command line tool that automates the setup of different environments. |
| All what is needed is a docker-compose.yml file that describes all services of the application and the template CLI project from [GitHub](https://github.com/streampipes/container-cli). |
| Afterwards, you need to split up your compose file and create an individual file for each service. Put those files in individual folders in the services folder. |
| Each folder should have the same name as the service name in the docker-compose file. That’s it! |
| Now you can use the CLI. |
| With the default commands you are able to start, stop, and configure the application. But how is this better than just using docker itself? |
| The advantage is the flexibility and extensibility of the tool. |
| You can extend the script with tasks you have to perform regularly, like cleaning up volumes, or setting up testing environments. |
| |
| |
| In the following we will describe the tool in more detail. |
| You can see all files and folders of the CLI Tool in the next listing. |
| The first file “container-cli.m4” contains the script. |
| We use [Argbash](https://argbash.io/), which eases the use of bash script parameters and flags. |
| In this file you can easily add new custom commands, flags or other functionalities. |
| The next file is the actual bash script. It is generated by argbash. |
| Since this file is generated automatically, you should not change anything. |
| The docker-compose.yml file is the main file. |
| This should contain all services, networks, or volume information that is relevant for all the other services of your application. |
| All your other services are located in the services folder. |
| For each service, create a folder with the name of the service and place a docker-compose.yml in the folder configuring the service. |
| Therefore, you can copy and paste the configuration from your current docker-compose.yml. |
| The script checks the services folder dynamically, this means you can add services at a later point in time without changing anything else. |
| In our example, we have four services: Backend, UI, database, and a test database containing data for the end2end tests. |
| Which services should be started when running the command **"container-cli start"** is defined in the active-service file. |
| This file contains the names of all services, each in one line, that should be started. |
| Often it is required to have multiple configurations of your app. You can save them in the templates folder. |
| By running **“container-cli set-template ui_developer”**, you can select the template ui_developer. |
| With this command, all services defined in the template are written to the active-services file. (e.g. the ui_developer template contains just the database and backend and the e2e-test template contains the backend, ui, and test-database). |
| |
| |
| <img class="blog-image" style={{maxWidth: '30%'}} src="/img/blog/2018-11-24/files.png" alt="Structure of the containter cli project"/> |
| |
| |
| The last file is the tmpl_env file. |
| It contains configuration variables for the individual services. |
| Those variables can also be changed by the bash script dynamically, because the tmpl_env file is moved to the .env file in the same folder. |
| We use the configuration for example to dynamically set the IP Address of the host system or set the application version. |
| To use a variable in a docker-compose file just write it in braces, as shown below. |
| |
| |
| <img className="blog-image" style={{maxWidth: '90%'}} src="/img/blog/2018-11-24/variables.png" alt="How to use Environment Variables"/> |
| |
| We hope this tool is helpful for your use case. |
| When you have any problems, feedback, or ideas for improvements, contact us or open an issue on [GitHub](https://github.com/streampipes/container-cli). |