Home

This wiki contains the getting started content posted to both Bluemix and the Accelerate developer advocacy site.

Accelerate intro

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 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, which allows for better distribution, scaling, and maintenance.

Accelerate overview

This application showcases the full power of containers and how can we move existing applications to the cloud seamlessly. We provide a full roadmap for developers who have been asked 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 be deployed on the Bluemix® Container Service. Each component runs in a separate container or group of containers.

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.

Leveraging the portability of containers, applications can be migrated and deployed easily to multiple Docker supported container platforms, as well as container groups can be leveraged to provide scalability.

Accelerate flow and diagram

The user interacts with GitLab via the web interface or by pushing code to a Git repo. 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. When serving repositories over HTTP/HTTPS, GitLab utilizes the GitLab API to resolve authorization and access as well as serving 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.

Accelerate components

IBM Container Service Gitlab Redis NGINX PostgreSQL Accelerate technology

Bluemix Container Service Accelerate links

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.

Accelerate blog post

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® 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.