Introduction
This article is part of a series of tips for Product Managers who want to get a feel for the technology, test it, install it, and demonstrate its capabilities.
Knowledge is power
At Taniwa, we use cloud machines where we deploy our own products (madriwa, mememtum, biolabeler, tanimage, etc.) and several of our clients’ products.
Some time ago, like many others, we realized that we would live better (have fewer problems and even work less!!!) if we used the following in both development and deployment/maintenance operations:
- Containers.
- Continuous integration.
- Continuous deployment.
And that’s what we do - we only deploy containerized applications, and for now without any orchestrator, using only docker-compose; and for CI/CD we use the SaaS service (GitLab).
GitLab is a standard DevOps tool that allows you to:
- Host application code in git repositories.
- Execute a set of actions called a pipeline when something happens in the code, to first compile it, run automated tests, and build the application.
- Then automatically deploy that application to most commonly used Cloud providers (Azure, AWS, GCloud, etc.) or to your own machines.
Pipelines run on shared machines in GitLab’s infrastructure and work fine if you’re not in a hurry for deployments and aren’t too paranoid about security.
But although we’re not too obsessed (with security at least), in our case GitLab needs to access our machines to deploy our application, and to do so with a bit more “privacy” we use GitLab runners.
GitLab Runner
GitLab Runner is an application that communicates with GitLab’s CI/CD system and is capable of executing the commands of the pipelines assigned to it.
You can deploy runners on GitLab’s infrastructure (managed runners) but also on your own machines. Runners are open source applications written in Go, which can also be deployed in containers (awesome!!!)
The steps to follow are:
- Launch the runner registration with GitLab