Home
This wiki contains the getting started content posted to both Bluemix and the Accelerate developer advocacy site.
Containers are a major trend in deploying applications in both public and private clouds. The recent 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, which allows for better distribution, scaling, and maintenance
This application showcases the full power of containers and how we can move existing applications to the cloud seamlessly. We provide a full roadmap for developers, helping them to migrate their apps to the cloud and leverage cloud-native packaging by using containers. We show you how a common multi-component application can deploy on the IBM Bluemix Container Service. Each component runs in a separate container.
IBM Bluemix Container Service combines Docker and Kubernetes to deliver: powerful tools, an intuitive user experience, and built-in security and isolation. You’ll be able to automate the deployment, operation, scaling, and monitoring of containerized apps over a cluster of independent compute hosts by using the Kubernetes API. 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.
- IBM Container Service
- Gitlab
- Redis
- NGINX
- PostgreSQL
Kubernetes Container Service Bluemix Container Private Registry
Auto-scaling for IBM Containers - Auto-scaling empowers businesses to assure clients with a fluid experience and cost optimization.
Tutorials and other resources for learning about IBM Bluemix Container Service - As a supplement to the IBM® Bluemix® Container Service documentation, try out these tutorials and other resources.
Going “cloud native” is the trend these days and containers are at the heart of this. At its root, being cloud native means structuring teams, culture, and technology to utilize automation and architectures to manage complexity and unlock velocity.
One of the key use cases for being cloud native is moving legacy applications to containers, which allows for better distribution, scaling, and maintenance. The most obvious benefit of containers is application portability where developers are able to run the exact same application on any Linux® machine. This freedom from servers means that you'll never have to be locked down to a specific cloud provider or even a virtualization technology.
In this journey, we show you how to deploy a distributed GitLab application on the IBM Bluemix® Kubernetes Container Service. GitLab is famous for its Git-based and code-tracking tool that programmers can easily install on their own local servers.
Taking different GitLab components (NGINX, Ruby on Rails, Redis, PostgreSQL, and more), you can deploy today with the help of the Bluemix Container Service.