Containers are a major trend in deploying applications in both public and private clouds. The widespread adoption of containers is largely due to the development of standards that are aimed at making them easier to use, such as the Docker image format and distribution model. One of the key use cases for containers is moving legacy applications to containers orchestration platforms like Kubernetes, which allows for better distribution, scaling, and maintenance.
This application showcases the full power of containers and show how you can move existing applications to the cloud seamlessly. We provide a full roadmap for developers, helping you migrate your apps to the cloud and leverage cloud-native packaging by using containers. We show you how a common multi-component application can be deployed on the IBM Cloud Kubernetes Service.
GitLab represents a typical multi-tier app, and each component will have its own container(s). The microservice containers will be for the web tier, and the state/job database will be with Redis and PostgreSQL as the database.
- The user interacts with GitLab via the web interface or by pushing code to a GitHub repository. The GitLab container runs the main Ruby on Rails application behind NGINX and gitlab-workhorse, which is a reverse proxy for large HTTP requests like file downloads and Git push/pull. While serving repositories over HTTP/HTTPS, GitLab utilizes the GitLab API to resolve authorization and access and serves Git objects.
- After authentication and authorization, the GitLab Rails application puts the incoming jobs, job information, and metadata on the Redis job queue that acts as a non-persistent database.
- Repositories are created in a local file system.
- The user creates users, roles, merge requests, groups, and more — all are then stored in PostgreSQL.
- The user accesses the repository by going through the Git shell.
Ready to put this code pattern to use? Complete details on how to get started running and using this application are in the README.