A Sprint In a Life of Devops at Yuk Recycle: Part 2

Hi! My name is Azka and I’m running out of time. Here’s what I did:

The Architecture

Software Architecture Diagram at Yuk-Recyle

Yuk Recycle is a project class from the class I’m taking. It consists of :

1. Two mobile apps, Mitra app and Customer app, which we decided to use flutter because of its promises that we liked.
2. Monolithic Golang backend, handling everything from authentication to response and request handling.
3. PostgreSQL db, a mainstream sql database with tons of advanced features
4. Firebase and Google API, for authentication and authorization, and also Maps functionalities
5. Docker, which connects everything.

Docker. And everything else.

This class I’m taking also requires all of it’s participant to use docker on Portainer to deploy their project. The workflow is pretty simple. All we need to do is:

1. Create and design a Dockerfile for each service
2. Build the image with a tag
3. Push the image to a privately hosted docker registry
4. Deploy the image we just pushed using a portainer.

It’s just that simple. But first let’s talk about docker.

Docker is a virtualization software that act like container — because it can’t reach the machines environment —that is pretty much secure (it has very few vulnerability and can only have one if configured to do so) and running generally on linux. We can use docker as development environment so everyone will be running the same version out of the container. But here it’ll be used as a production service that can be scaled as the demand goes up.

A docker container runs a mini version of an OS. It called an Image. A docker image created using by building the image according implementation defined in a Dockerfile. A Dockerfile consists of docker-defined command that can be found on https://docs.docker.com/engine/reference/builder/. After defining a Dockerfile, now we build the image using docker build command. This will produce an image according to corresponding Dockerfile. This image that we created can’t do anything yet. We need to run it first using docker run . Docker run command has a lot of arguments that can be configured according to our needs, such as its network, volumes, etc. But this configuration can get very messy very fast.

This is where docker-compose comes in. Docker can be used along with docker-compose. It is some sort of orchestration tool — a simple one — but powerful enough for our need right now. It uses yaml config file, containing arguments that usually attached to docker run command, to run multiple docker service and can be ran using single command, docker-compose up, and we’re ready to go. It also has handful of other useful features that I can use in this project.

Illustration of how useful a docker-compose is

The Portainer

Portainer is simply a GUI version of good ol’ CLI docker client. It does make it easier for some stuff, like container duplication etc., but it also make it harder for some other stuff like automation.

Implementation

Now we know what docker and docker-compose is. So here’s the implementation of my Dockerfile.

The first line, FROM golang:latest basically pulls an image from docker registry with a tag golang:latest. This enables us to reuse existing image and extends it further to our needs.

The next two lines will copy current working directory where the docker build called and put it in our docker image.

The last two lines will fetch our golang dependencies, and run a command go run main.go which is an entry point for our main API.

In our project, this Dockerfile will be used in collaboration with docker-compose.yml, which will contains the arguments and configuration necessary for our project.

Our docker-compose will consists of two services. One for the database, and one for our golang backend API.

The db service is running a postgres image from docker registry. This much should be enough since I haven’t see any problem with current configuration.

The app service will be running our image using Dockerfile that we have wrote earlier. It will also opening expose port 8000 from our container to the outside world with port 8000. It will have a dependency to db service so if the db hasn’t started yet, this app service wont run. For our app service to be able to connect to db service, we need to create a link, which we already defined on clause links.

With this setup, I was able to deploy the app smoothly on local machine. I wanted to use this docker-compose setup on Portainer, but for some reason, which I think it caused by our Portainer not using docker swarm, But I will continue to do some research if it possible to overcome this obstacle.