« Previous 1 2
Automatic build and deploy with OpenShift and GitLab CI
Code, Build, and Deploy
Automated Build with S2I
As I mentioned earlier, OpenShift has CI/CD tools for accelerated application development. You can easily turn source code into running applications with S2I capabilities. This is the tool used when you type the oc new-app
command (line 19). S2I produces ready-to-run images by injecting source code into a container and letting the container prepare that code for execution. As Figure 7 illustrates, it performs the following steps:
1. Start a container from the builder image, depending on the code language you use for your application.
2. Download the application source.
3. Stream the scripts and application sources into the builder image container.
4. Run the assemble script (from the builder image) and save the final image.
In this example, OpenShift Origin provides S2I-enabled Node.js images for building and running Node.js applications [18]. The Node.js S2I builder image assembles the application source with any required dependencies to create a new image containing the Node.js application. This resulting image can be run either by OpenShift Origin or by Docker. S2I provides, at the moment, official images for different languages – Node.js, Perl, PHP, Python, Ruby, Wildfly – but it is also possible to use customized images.
Now, when a developer makes a new commit/push on the repository, the code is cloned from GitLab, built, and tested. Then, OpenShift builds a Docker Node.js image with S2I capabilities. The Docker image is deployed in a fresh new container in the development environment. The last container is deleted and the new application related to the last commit replaces it (Figure 8).
Conclusion
In this article, I described the steps needed to create a working CI/CD pipeline by combining OpenShift and GitLab CI. I showed how it can be achieved with a slide presentation example, and I showed that setting up a CI/CD process with OpenShift is within the reach of every developer.
Currently, I am improving this CI/CD process by adding more phases, such as checking the service quality and monitoring OpenShift resources with tools like Prometheus [19] and Grafana [20].
Infos
- OpenShift: https://www.openshift.org/
- GitLab: https://gitlab.com/
- CETIC: https://www.cetic.be/?lang=en
- reveal.js: https://github.com/hakimel/reveal.js/
- View slides: http://slides.openshift.cetic.be/
- CETIC Git repository: https://git.cetic.be/OpenShift/slides
- Docker: https://www.docker.com/
- Kubernetes: https://kubernetes.io/
- S2I: https://docs.openshift.org/latest/using_images/s2i_images/index.html
- Minishift: https://github.com/minishift/minishift
- OpenShift service accounts: https://docs.openshift.com/container-platform/3.6/dev_guide/service_accounts.html
- "GitLab Continuous Integration (GitLab CI/CD)" Original image: https://docs.gitlab.com/ee/ci/
- GitLab Runners: https://docs.gitlab.com/runner/executors/
- GitLab Runner template for OpenShift: https://gitlab.com/gitlab-org/omnibus-gitlab/tree/f04b5c4443b3a98011577cdd7c9de766a287531e/docker/openshift
- OpenShift.gitlab-ci.yaml file template: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/vendor/gitlab-ci-yml/OpenShift.gitlab-ci.yml
- Alpine Docker image with the OpenShift client: https://hub.docker.com/r/ebits/openshift-client/
- "Development workflows with Fuse Integration Services (FIS)" by Frédéric Giloux: https://developers.redhat.com/blog/2016/09/22/development-workflows-with-fuse-integration-services-fis/
- Node.js S2I image: https://docs.openshift.org/latest/using_images/s2i_images/nodejs.html
- Prometheus: https://prometheus.io/
- Grafana: https://grafana.com/
« Previous 1 2
Buy this article as PDF
(incl. VAT)