OpenShift.IO: all-in-one development platform and CI / CD
Total containerization and rethinking of the role of containers in the process of development and infrastructure development could not but encourage the main adherents of the open source world to further achievements. Red Hat is confidently pushing its line, and if a few years ago OpenShift was only PaaS, today it is more. OpenShift itself is understandable, but not simple. Making the process of managing containers and deploying applications as painless and safe as possible is the main task pursued by OpenShift, and it is worth noting that the guys from Red Hat have succeeded in this. But, by itself, OpenShift does not bring any closer to the cherished dream - to provide the developer, PM, QA engineer with the environment where everything will be. This is such a perfect world without Jira or RedMine, without endless Jenkins slaves, unfinished updating of styling, various IDEs that behave differently with different projects, without manual configuration of projects on GitHub. This ideal world is a project that Red Hat announced relatively recently, namely in May 2017, and his name is openshift.io .
To squeeze everything out of OpenShift, several opens source projects were adopted (as is usually the case with Red Hat, whose business is built around open source) - fabric8 and Eclipse Che. First things first.
OpenShift copes well with the deployment of applications in Kubernetes podah. But, hardly the platform gives absolutely everything that devops, PMs and ordinary coders may need. Then Fabric8 , the integrated development platform for Kubernetes, comes to the rescue.
')
The basic idea is that it is not enough just to shut down the application. We need to start over again, namely with the creation of the project and source control. So, by running Fabric8 locally, or logging into your openshift.io account (currently closed beta), you will be asked to create a space in which you specify the location of the sources, as well as select the type of pipeline. Yes, openshift.io will automatically create for you several namespaces with service hearths, depending on the type of CI / CD selected.
For example, you can order one of the following chains:
As you can see, we go from simple to complex. That is, you can simply use Jenkins for CI, and for you slaves will go up in sub-fields, as soon as the webhook is triggered on GitHub (the provider may be different). Or, after the Jenkins build, the image will be launched into the local registration and reused in stage neymspace. The final configuration involves promotion from styling to production - in this case it does not happen automatically, but only at the request of the user.
Fabric8 itself unfolds in OpenShift in the form of hearths. In a running form, with 1 project that uses advanced CI / CD - Build release> stage> prod - as many as 39 running containers were counted - this is an authentication server (this is KeyCloak, by the way), IPA server, databases, service files, Jenkins and its slaves, Eclipse Che and related workspaces. Stock up on RAM, in general :)
By the way, about Eclipse Che . The picture of Openshift.io would not be complete if the development did not originate directly in the browser. In the CI / CD scripts, there are clearly not enough commits that will pull webhooks. And Openshift.io knows where you will come from, offering to develop applications in the same place, in OpenShift. Red Hat has long been interested in Eclipse Che and even bought Codenvy, whose developers are the founding fathers of the project. Interestingly, over the past 2 years, the web IDE either went bankrupt or was absorbed by the giants (how not to remember the departure of Cloud 9 under the AWS wing). Well, it is, by the way :)
Eclipse Che runs in the OpenShift pod and creates the workspace of the desired configuration. That is, after creating the space and importing the project, Eclipse Che imports the source code and opens it into the online IDE, right here, without departing from the cash register. Che workspace is under a set of servers and other software that ultimately provide the IDE in the browser. Workspaces are started and stopped on demand, that is, when the user needs it. Now the chain looks more consistent:
import - code and push - CI / CD
But this is not the end. In addition to writing code, CI and application deployment, there is also planning. In order to provide everything in one box Planner was developed. Such an analogue of Jira, of course, is much simpler, but the development of the platform is still boiling, so we should expect improvements.
Fabric8 and its commercial counterpart, openshift.io, are slowly but surely moving (or trying to go) to solving complexly the pains and problems of development teams, and first of all devops. At the moment, the solution is damp and clearly not ready for real life projects, but after all, OpenShift was not immediately built. Banks, fin. Institutions, companies with the strictest security policies are potential consumers of such a solution. Especially under the brand name Red Hat. But, do not forget that behind each product of the company there is an open source project - take it and install it, there would be time and a desire to poke around.
Wait and see. Moreover, in openshift.io Red Hat is developing an analytics system. The company analyzes hundreds of thousands of open source projects to suggest how to improve your code, suggest a new version of the library, report vulnerabilities, etc.
Microsoft, by the way, is also trying to promote a similar platform - VSTS . But, the difference between Red Hat is that they made a bet on Kubernetes, and, apparently, did not lose.
To squeeze everything out of OpenShift, several opens source projects were adopted (as is usually the case with Red Hat, whose business is built around open source) - fabric8 and Eclipse Che. First things first.
OpenShift copes well with the deployment of applications in Kubernetes podah. But, hardly the platform gives absolutely everything that devops, PMs and ordinary coders may need. Then Fabric8 , the integrated development platform for Kubernetes, comes to the rescue.
')
The basic idea is that it is not enough just to shut down the application. We need to start over again, namely with the creation of the project and source control. So, by running Fabric8 locally, or logging into your openshift.io account (currently closed beta), you will be asked to create a space in which you specify the location of the sources, as well as select the type of pipeline. Yes, openshift.io will automatically create for you several namespaces with service hearths, depending on the type of CI / CD selected.
For example, you can order one of the following chains:
- Build release
- Build release> stage
- Build release> stage> prod
As you can see, we go from simple to complex. That is, you can simply use Jenkins for CI, and for you slaves will go up in sub-fields, as soon as the webhook is triggered on GitHub (the provider may be different). Or, after the Jenkins build, the image will be launched into the local registration and reused in stage neymspace. The final configuration involves promotion from styling to production - in this case it does not happen automatically, but only at the request of the user.
Fabric8 itself unfolds in OpenShift in the form of hearths. In a running form, with 1 project that uses advanced CI / CD - Build release> stage> prod - as many as 39 running containers were counted - this is an authentication server (this is KeyCloak, by the way), IPA server, databases, service files, Jenkins and its slaves, Eclipse Che and related workspaces. Stock up on RAM, in general :)
By the way, about Eclipse Che . The picture of Openshift.io would not be complete if the development did not originate directly in the browser. In the CI / CD scripts, there are clearly not enough commits that will pull webhooks. And Openshift.io knows where you will come from, offering to develop applications in the same place, in OpenShift. Red Hat has long been interested in Eclipse Che and even bought Codenvy, whose developers are the founding fathers of the project. Interestingly, over the past 2 years, the web IDE either went bankrupt or was absorbed by the giants (how not to remember the departure of Cloud 9 under the AWS wing). Well, it is, by the way :)
Eclipse Che runs in the OpenShift pod and creates the workspace of the desired configuration. That is, after creating the space and importing the project, Eclipse Che imports the source code and opens it into the online IDE, right here, without departing from the cash register. Che workspace is under a set of servers and other software that ultimately provide the IDE in the browser. Workspaces are started and stopped on demand, that is, when the user needs it. Now the chain looks more consistent:
import - code and push - CI / CD
But this is not the end. In addition to writing code, CI and application deployment, there is also planning. In order to provide everything in one box Planner was developed. Such an analogue of Jira, of course, is much simpler, but the development of the platform is still boiling, so we should expect improvements.
Fabric8 and its commercial counterpart, openshift.io, are slowly but surely moving (or trying to go) to solving complexly the pains and problems of development teams, and first of all devops. At the moment, the solution is damp and clearly not ready for real life projects, but after all, OpenShift was not immediately built. Banks, fin. Institutions, companies with the strictest security policies are potential consumers of such a solution. Especially under the brand name Red Hat. But, do not forget that behind each product of the company there is an open source project - take it and install it, there would be time and a desire to poke around.
Wait and see. Moreover, in openshift.io Red Hat is developing an analytics system. The company analyzes hundreds of thousands of open source projects to suggest how to improve your code, suggest a new version of the library, report vulnerabilities, etc.
Microsoft, by the way, is also trying to promote a similar platform - VSTS . But, the difference between Red Hat is that they made a bet on Kubernetes, and, apparently, did not lose.
Source: https://habr.com/ru/post/340446/
All Articles