Ansible-Terraform Workspace. Part 4

development environment with Ansible, Terraform, and lots of other applications in one docker image.

7 min readSep 19, 2021

Ansible-Terraform Workspace Part 1
Ansible-Terraform Workspace Part 2
Ansible-Terraform Workspace Part 3

This is Part 4 of the publications about Ansible-Terraform workspace — a docker image, that contains a toolkit to work with Ansible and Terraform, including several browser-based applications to schedule jobs, visualize infrastructures, terraform plan visualization, dashboard of Ansible playbooks, and more.

Part 4 is about common actions in Ansible-Terraform workspace, its extension, and management of workspaces.

Common workspace actions

Common actions you’d do in the workspace

installation of new applications and runtimes
edit files, write code, scripts
build, compile and execute code
start/stop applications and services
schedule tasks and scripts
process data

Install applications

Use workspace workspace terminal to install new applications. Install with sudo apt install. The default abc user is allowed to install packages.

For example, in order to install Emacs text editor open workspace terminal, and execute

sudo apt install emacs

Schedule jobs with Cron

Schedule execution of any task with cron — a time-based job scheduler in Unix-like computer operating systems.

Open workspace terminal, and execute

crontab -e

(chose [1] nano as editor on the first time) In the end of the opened file add line

* * * * * echo $(whoami) >> /home/cron.txt

This will print every minute username to file /home/cron.txt . (Hit Ctrl+X to exit nano)

Hint: example of cron job definition:

.---------------- minute (0 - 59)   
|  .------------- hour (0 - 23)
|  |  .---------- day of month (1 - 31)
|  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
|  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
|  |  |  |  |
*  *  *  *  *  command to be executed

NOTE you can disconnect from the image and close terminal — cron will continue working.

Instead of cron you might want to use Cronicle — a tool with Web UI, and a great list of features that will provide you with the dashboard, list of executions and statistics, even let you ser limis on resources for each jobs, and create depenndencies between jobs.

Python

Python and Pip are installed. To use python console, open workspace terminal and execute

python

install python package with pip, for

pip install pandas

If you are planning to work with python, we recommend to install IPython, that provides a rich toolkit to help you make the most of using Python interactively. Install and start ipython

pip install ipython
ipython

Node.js

We recommend to use nodeenv to create different node environments.

For example, open workspace terminal, create folder npmgui, and activate environment with node v. 12.18.3 and npm v.6.0.0

cd /home
mkdir npmgui; cd npmgui
nodeenv --node=12.18.3 --npm=6.0.0 env

Let’s install the package and start a Node application

. env/bin/activate && npm i -g npm-gui
npm-gui 0.0.0.0:8030

Open your browser on http://localhost:8030/

NOTE: If you close the terminal, the application will stop. See how to start applications that remains live after closing a workspace terminal

Run applications and services inside the workspace

If you want the application to keep running after the workspace terminal is closed start it with “&!” at the end.

For example, in the last section, we started npm-gui tool with the command npm-gui 0.0.0.0:8030. If you close the workspace terminal, this application will stop running. To keep it running after the terminal is closed, execute

npm-gui 0.0.0.0:8030 &!

Now, if you disconnect from the workspace and close the terminal, the application will continue running in the workspace, until the workspace is stopped.

Manage workspaces

Workspace is just a docker container. You can start, stop, delete and do anything you can do with docker images and containers.

There are two concepts to keep in mind: images and containers. Images are workspace blueprints. For example, alnoda/ansible-terraform-workspace — is an image. When you execute this command

docker run --name space-1 -d -p 8020-8035:8020-8035 -p 9000:9000 alnoda/ansible-terraform-workspace

you create a container called space-1 from the image alnoda/ansible-terraform-workspace. You can create any number of containers, but you need to map different ports to each of them.

Container — is your workspace. You can start, stop and delete them. You can run multiple workspace containers at the same time, or work with one workspace at a time.

From the workspace (which is a container) you can create a new image. This is called commit docker image. Essentially, this means “take my workspace and create a new image with all the changes I’ve done in my workspace”

Start and stop workspaces

The workspace started in daemon mode will continue working in the background.

See all the running docker containers

docker ps

Stop workspace

docker stop space-1

Workspace is stopped. All the processes and cron jobs are not running.

See all docker containers, including stopped

docker ps -a

Start workspace again. Processes and cron jobs are resumed.

docker start space-1

Delete workspace container (all work will be lost)

docker rm space-1

Create a new workspace image

Having made changes, you can commit them to creating a new image of the workspace. In order to create a new workspace image with the name “space-image” and version “0.2” execute

docker commit space-1 space-image:0.2

Run new workspace with

docker run --name space2 -d space-image:0.2

The new workspace accommodates all the changes that you’ve made in your space-1. Hence you can have versions of your workspaces. Create different versions before the important changes.

Manage workspace images

See all docker images

docker images

Delete workspace image entirely

docker rmi -f alnoda/ansible-terraform-workspace

NOTE: you cannot delete an image if there is a running container created from it. Stop container first.

Save and load workspace images

After you commit the workspace container and create a new image out of it, you can push it to your docker registry or save it in a file.

Save workspace as a file

Assuming you created a new image space-image:0.4 from your workspace, you can save it as a tar file

docker save space-image:0.4 > space-image-0.4.tar

We can delete the image with

docker rmi -f space-image:0.4

And restore it from the tar file

docker load < space-image-0.4.tar

Push workspace to a docker registry

A better way to manage images is docker registries. You can use docker registries in multiple clouds. They are cheap and very convenient.
Check out, for example, Registry in DigitalOcean or in Scaleway container registry. There are more.

Pushing image to the registry is merely 2 extra commands: 1) tag image; 2) push the image

You will be able to pull images on any device, local or cloud.

Move workspace to the cloud

Ease of running workspace in cloud, and ability to move workspaces between local machine and remote server — is one of the main features of the workspace and the reason why the workspace is entirely in docker.

It is often a case that an experiment, which started on a personal notebook requires more computational resources, must be running for a long period of time, or executed periodically. All of these cases are the reasons to move a workspace to the cloud server. Usually, it is a hassle, but this workspace can be moved to the remote server easily.

The easiest way to move a workspace to the cloud is to get your private docker registry. Then moving a workspace from a laptop to a remote server is only 3 commands:

Commit workspace to the image
Push workspace to your docker registry
ssh to a remote server, and run workspace there

If you don’t want to use container registry, then there are 2 steps more involved:

Commit workspace to the image
Save image to file
Copy file to a remote server. There are many options (launch file exchange workspace on the remote server; use Cyberduck; use SCP)
Load workspace image from a file on the remote server
Start workspace on the remote server

Workspace Documentation

Workspace can easily be customized for your specific needs. You can also use Workspace for a complex project and might need a tool to write remarks, plans, action plans. As well as architectural artifacts for the components you wish to implement. Often it is also needed to store somewhere snippets of code or shell commands that you often use in your work. It would be uncomfortable to use an extra tools or solutions outside of the Workspace to store such remarks.

Because Workspace is a completely self-contained environment, it includes tools to make remarks, plans, store pieces of code, write anything, and even build complete static documentation websites that you can host on GitHub Pages for example.

MkDocs is a part of the workspace, and its dev server is up and running every time you start the Workspace. In fact, the workspace UI (port 8020 by default) — is served by the MkDocs dev server.

You can easily modify the UI, add more pages or update existing pages. The changes will be updated immediately without the need to do anything.

MkDocs project is located in the /home/docs/ folder. It has a subfolder called docs (so it is /home/docs/docs/) where all the Markdown documents are stored. Simply create new file there. And add a reference about this file to the MkDocs config /home/docs/mkdocs.yml. You will see that the new page has appeared in your Workspace UI - it has live reload, and you don't need to do anything, just write in the markdown files.

You can easily build a beautiful static website from this documentation

cd /home/docs/ && mkdocs build -d /home/static-server/my-doc-website

The resulting HTML website is in a folder /home/static-server/my-doc-website, you can view it with Static File Server and download to local with Filebrowser