Following the first part, I promised to talk more about containers and how you can set your development in less than 10 minutes. So here it is.

Containers

What is a container?

A good practice is to always containerize your projects and environments as that allows them to run separately from each other, keeping everything safe. Containerizing your software means that it will run as an isolated application without the need for a virtual machine as it is an OS-level virtualization. The main idea is that, since the processes are isolated, you can run multiple containers and they would never interfere with each other and as such, changing different environments will never break your already existing applications. Portability is a second benefit; you can easily run your container on any platform and can push it to your server as a single package and run it online directly.

Docker enters the chat

The introduction of docker in 2013 had the biggest impact on container technology. Docker was built based on LXC (linuX containers) and later replaced it with its own container manager called libcontainer. Docker is a container engine that uses the Linux Kernel features like namespaces and control groups to create containers on top of an operating system. So basically, it makes creating a container easy… well, easier.

It immediately shined between the competition as it had an easy-to-use GUI and was capable of having multiple applications with different OS requirements run on a single OS. In addition to providing system resource isolation, Docker also provides networking configuration and isolation. It achieves this by creating virtual networks that allows for fine-grained control of inter-container communication, and also gives the user control over which network interfaces are exposed on the host system. These features add an extra layer of security while giving the user the flexibility to finely control the communication layer of their applications.

Containers are as complicated as they sound and might make you rip your hair off, but they are well worth it and will take your development to a new level.

How to use docker

To start up with docker, you need to install and run it. After that, you need to obtain the source code for the application you want to containerize. Then you will need to create a docker image file from a Dockerfile. A container image is essentially a file including executable code that is able to run an isolated process on your machine. It includes system libraries, system tools, and other settings needed to run a software on a containerization platform.

These are a few keywords that you can use:

• A valid Dockerfile must start with a “FROM” instruction. It initializes a new build stage and sets the Base Image for subsequent instructions. The image can be any valid image – it is especially easy to start by pulling an image from the Public Repositories.
• The “WORKDIR” instruction sets the working directory instructions that follow it in the Dockerfile. If it does not exist, it will be created even if it is never used.
• “ARG” are also known as build-time variables. They are only available from the moment they are ‘announced’ in the Dockerfile with an ARG instruction up to the moment when the image is built. Images cannot access them once built.
• “ENV” are variables that are available during the build and after it.
• The keyword “RUN” allows you to execute commands at build time (when the image is being created), this allows you to make modification to the underlying image by adding, removing and/or modifying the filesystem of the image, which allows you to customize your image for your needs.
• From within this dockerfile you will be able to copy your application with “COPY”. Its role is to duplicate files/directories in a specified location in their existing format. This means that it does not deal with extracting a compressed file, but rather copies it as-is.

• A dockerfile needs to include at least a “CMD” or an “ENTRYPOINT” instruction. Both define which command gets executed when the container is run.

  • “ENTRYPOINT” should be defined when using the container as an executable.
  • “CMD” should be used as a way of defining default arguments for an ENTRYPOINT command or for executing an ad-hoc command in a container.
  • “CMD” will be overridden when running the container with alternative arguments.

You will then need to build your dockerfile into an image with the command “build” and you will be able to start and stop those containers when you need.

I recommend reading docker's documentation because honestly there are too many things to keep track of.

myceleum to the rescue!

As developers, we have been through that hell a couple of times, and though experience definitely helps, mistakes still happen and sometimes environments just break. Which is where myceleum comes into play.

A myceleum workspace is essentially a docker container running ubuntu with language SDKs and runtime installed on top of it. It allows you to very easily setup your environment with every tool already mentioned within the click of a button.

It has multiple features including IDE integration, which allows you to choose your preferred IDE, and environment sync which lets you sync across machines. Working in teams is made easy by syncing an environment with everyone. And syncing across personal devices allows you to always have access to your environments.

Getting started with myceleum is very straightforward. You need to have docker installed and running to run myceleum so make sure to download it. Once installed, you will be greeted with the main interface where you can just choose your desired spore and download it. A container image will be installed, and you will be able to configure it. The spores are preconfigured based on best practices, but you can edit all environment variables and packages.

myceleum will ask you to specify your project path and you will be able to easily select your preferred shell and IDE. The IDE integration feature allows you to feel at home by using the one you feel comfortable with. The aim here is to make the developer as comfortable as ever by providing a high level of customization to the environments.

After that, you are done! You can run the spore and start coding without having to worry about anything breaking as the processes are isolated.

And finally, the ending we all needed.

Creating your environments should not be hard, you should not have to tear your hair out nor think about changing your job for about 12 times (this is surely not a cry for help). And that’s why myceleum is the easiest tool to set your environment! No need to look for different tools or versions, just worry about perfecting your code!