You have a complex monolithic system that is critical to your business. You’ve read articles and would love to move it to a more modern platform using microservices and containers, but you have no idea where to start.
If that sounds like your situation, then this is the article for you. Below, I identify best practices and the areas to focus on as you evolve your monolithic application into a microservices-oriented application.
We all know that net new, greenfield development is ideal, starting with a container-based approach using cloud services. Unfortunately, that is not the day-to-day reality inside most development teams. Most development teams support multiple existing applications that have been around for a few years and need to be refactored to take advantage of modern toolsets and platforms. This is often referred to as brownfield development.
Not all application technology will fit into containers easily. It can always be made to fit, but one has to question if it is worth it. For example, you could lift and shift an entire large-scale application into containers or onto a cloud platform, but you will realize none of the benefits around flexibility or cost containment.
This is part two of our series on using GitLab and Rancher together to build a CI/CD pipeline, and follows partone from last week, which covered deploying, configuring, and securing GitLab in Rancher. We’ve also madethe entire walkthrough available for download.
Using GitLab CI Multi-Runner to Build Containers
GitLab CI is a powerful tool for continuous integration and continuous delivery. To use it with Rancher, we’ll deploy a runner that will execute jobs.
Launching the Runner
There are several ways that runners can be deployed, but since we’ll be targeting building containers from our repositories, we’ll run a Docker container that has direct access to /var/run/docker.sock to build images that are siblings to itself.
In Rancher, add a service to your Gitlab stack
Set it up with the following configuration:
When the container launches, it will create a default configuration in /etc/gitlab-runner, to which we’ve connected a volume. The next step is to register the runner with your Gitlab instance.
The options that I’m setting below are correct for a basic runner that will build any job. You can also limit runners to specific repositories or use other images. Read the documentation from Gitlab to learn what options are best for your environment.
containerd is an industry-standard core container runtime that was initially released by Docker Inc. in December 2015 and contributed to CNCF in March 2017. We’ve received a number of questions about the project, so I thought I would provide you my perspective as well as some preliminary thoughts on how how Rancher Labs will leverage it.
Docker, Kubernetes, and containerd
The containerd project represents an important step in the evolution of the Docker platform. In the beginning, the Docker engine was quite simple. It merely consisted of the minimum support required to run Docker images on a single host. Over the last few years, however, the Docker Engine has evolved significantly. The Docker engine now includes sophisticated support for cluster management, multi-host networking, and scheduling. Today, Docker is actually closer to a platform like Kubernetes, even though Kubernetes was created to manage Docker. Read more
I am incredibly excited to be joining such a talented, diverse group at Rancher Labs as Vice President of Business Development. In this role, I’ll be building upon my experience of developing foundational and strategic relationships based on open source technology. This change is motivated by my desire to go back to my roots, working with small, promising companies with passionate teams.
I joined Docker, Inc. in 2013, just as it started to bring containers out of the shadows and empower developers to write software with the tools of their choice, while redefining their relationship with infrastructure. Now that Docker is available in every cloud environment, embedded in developer tools, and integrated in development pipelines, the focus has shifted to making it more efficient and sustainable for business. Read more
GitLab is, at its core, a tool for centrally managing Git repositories. As one might expect form a platform that provides this service, GitLab provides a robust authentication and authorization mechanism, groups, issue tracking, wiki, and snippets, along with public, internal, and private repositories.
GitLab goes further by including a powerful continuous integration (CI) engine and a Docker container registry, allowing you to go from development to release inside of the same utility. It continues by adding two more powerful open source software utilities: Prometheus for monitoring, and Mattermost for team communication. The platform has a solid API and integrates with existing third-party systems like JIRA, Bugzilla, Pivotal, Slack, HipChat, Bamboo, and more.
All of this begs the question: why use GitLab instead of using SaaS services directly? The answer lies in personal taste. For most people, paying SaaS providers for the services that they provide is an excellent solution. You can focus on building your application and let them worry about maintaining the tools. What if you already have infrastructure with spare capacity? What if you just want private repositories without paying for that privilege? What if you did the math and determined that you can save money by hosting it yourself? What if you just want to own your own data?
Bringing services in-house opens you up to the risk of spending more time managing them and getting them to talk to each other, which is why GitLab truly shines as an option. With one click and a few minutes of configuration, you can be up and running with a complete solution.