OpenShift 3: Docker-based private PaaS platform
OpenShift is a very promising private PaaS solution that reduces the time from project start-up to automatic build applications and deployment, which supports the vast majority of Web architectures and will become a private PaaS platform based on Docker Of the reference.
OpenShift is a private PaaS (Platform-as-a-Service) solution that is primarily used to build, deploy, and run applications in a container. It is based on Apache 2.0 licensed open source software, and issued two versions, one is the community version, one is the enterprise version.
- 2015 Docker and other subversive trends in IT
- Kubernetes Surveillance Heapster source implementation
- Meso + ZooKeeper + Marathon + Docker Distributed Deployment Build PaaS Cloud Platform Practice (1)
- How is the container that is better than all the financial industry?
- DassOne Share (79): Building Enterprise-Class PaaS Cloud Platform Practice Based on Container Technology
- Deploy private PaaS: merits, boring and some nonsense
The third edition of the origin
Starting in July 2014, OpenShift has focused on researching a very good project that integrates the technology architecture with Docker and Kubernetes (now a very common thing).
Starting this project a year ago is a bold and risky decision for OpenShift. Indeed, when the cloud platform competition in the peak of the white-hot period, and this time OpenShift decided to risk the risk of starting such a very important reconstruction project, the risk comes mainly from their need to stop the development of new features and compromise between the old version Compatibility issues. But now, we believe they made the right decision.
So far, the community version has combined 86 development volunteers on GitHub (GitHub is one of the 10 most active projects on Red Hat). Had 16 iterations in 12 months and had just released the first edition.
Although this program is mainly driven by Red Hat, but it is very dependent on Kubernetes (from Google). Which triggers the question of who will dominate and dominate, depending on the collaboration and version benchmarks between the two companies, what happens when Google develops new features? Will they be concerned about Kubernetes or OpenShift? Obviously, there is no answer to this question.
However, Google's technical support department has confirmed that the two companies at the same time will only lead to OpenShift bring more benefits. It will become more competitive than Docker Enterprise Edition (machine, build and group).
Automatically build and deploy applications: how to do this
OpenShift V3 provides three ways to build applications automatically.
- Docker-File mode: Automatically builds a Docker container by providing OpenShift a URI to the source manager of Docker-File and its dependencies.
- Source-To-Image Mode (STI): Allows an application to be automatically created by submitting the application's source code to OpenShift. (Like the buildpacks in Heroku).
- Custom build mode: allows you to provide your own application to build the logic, which is achieved by providing an OpenShift Docker image.
OpenShift 3 also allows you to define an automated deployment policy when the registry has a new application image release or an application configuration has an update.
To accomplish these build and deployment features, OpenShift 3 provides the ability to define its own application blueprints as template files in JSON or Yaml format. These blueprints describe the application architecture topology and container deployment strategy. The following diagram describes how to combine the different components of a template in OpenShit for a three-tier application.
In the "template" in the combination of components, to some extent inherited the concept of Kubernetes, need to remember the following main object.
- A "POD" is a Docker container's runtime environment (if we need to share local resources, we will deploy two categories of containers in a separate POD)
- A "service" is an entry, abstracting an equal access load to a group of identical containers, theoretically, at least one service corresponds to an architectural layer.
- A "service deployer" or "deployment configuration" is an object that describes the deployment strategy for a trigger-based container. (For example, when the Docker registry has a new version of the image, you need to redeploy).
- A "copy controller" is a technical component that is primarily responsible for the flexibility of POD.
- A "route" is used to reveal an application's entry (domain name resolution, hostname or VIP)
Through its multiple deployment mechanism and the ability to set its own "blueprint", OpenShift 3rd Edition is suitable for most complex application architectures.
The elegant architecture under the hood
The OpenShift 3 architecture can be deployed as standalone mode (using the Docker image " openshift / origin ") or as a distributed mode deployment. In the subsequent case, two server roles, a master server, and a node were used.
The function of the "master server" node is:
- Process API requests from the command line or Web interface.
- Build the image and deploy the container.
- To ensure the flexibility of POD replication.
The "master server" relies on the distributed directory based on etcd, which is mainly used to provide configuration sharing and service discovery.
"Node" is mainly used as a PODS host and a runtime container (application and registry).
The architecture is distributed, extensible, and resilient. But the platform itself does not support automatic scalability: the current capacity of the underlying server and the server can only be manually adjusted.
The platform can be accessed and managed through its own REST API, CLI, Web portal.
OCTO point of view
OpenShift 3 has set up an interesting bridge between the "Platform as a Service" and "Container as a Service" world, Red Hat has put forward a bold solution and a state-of-the-art architecture, and we are very grateful to the "blueprint" specifications Format, to define the schema requirements of the architecture and the layout of the deployment.
In the Beta 3 release, the OpenShift platform did not focus on the operability of the platform, and it was not recommended for use in a production environment, but the user's problems could be found on the roadmap.
- Implement log aggregation with ElasticSearch – Logstash – Kibana or Fluentd .
- Monitor with Heapster.
- Easy to achieve cluster deployment.
We believe that modeling an application in OpenShift 3 will be a new job and it will require new skills so that appropriate questions can be raised, such as how to organize containers Should I use routing or services? How do I handle data (consistency, replication, backup)? How do I manage multiple leases? How do I integrate the development and deployment of software factories?
All in all, OpenShift is a very promising private PaaS solution that reduces the time from project start-up to automatic build applications and deployment, which supports the vast majority of complex Web architectures, even for data management and external service integration Has not been fully applied.
We believe that OpenShift 3 is in control of everything, and it will be a reference for Docker's private PaaS platform.
Original link: OpenShift 3: private PaaS with Docker (translation: Jackson LEE)