Srinivas, I’d like to throw another option your way.
Eclipse —> Git —> Jenkins to build and create artifacts —> Jenkins Docker Plug-in to create image -> push image to the built-in openshift docker registry Something you’ll need before the above pipeline, is a configuration already in place on the openshift cluster (deployment config, pointing to the built-in registry, service, route, etc…) and the build-in registry needs to be exposed. We are using this in my environment and it works well. We are using our own existing build processes that we’ve already had in place without any extra unnecessary work, and simply plugging in openshift to complete the deployment. Sending an image to the internal registry is essentially what the openshift native build process does; therefore, one is able to abuse the native extensions that openshift has built to complete deployments in an automated fashion. We do, however, utilize multiple openshift clusters. One for testing and one for prod as an example. So we simply have two deploy jobs that get kicked off appropriately. If by chance you utilize the same cluster for both dev and prod, you can probably take the above model and utilize tagging appropriately to send the final deployment image into production. We like this as we are able to integrate our existing large and ugly pipelines that have already been fine tuned to our liking. It also allows our deployment engineers to continue the path they already do without having to learn a new system. The downside I see to this is that we may be missing out one some features that openshift may provide in their building process. It also forces some undue troubleshooting as we are building our own docker containers which is a little difficult for our developers to test with locally. Things we’ve had to deal with are documented well within openshift, and most if it concerns the use of SCC’s and image file permissions. Though, thus far, it hasn’t been terrible. -- John Skarbek On March 18, 2016 at 02:57:28, Srinivas Naga Kotaru (skotaru) (skot...@cisco.com<mailto:skot...@cisco.com>) wrote: We’re thinking what is the best approach for our code deployment and promotion. This is our proposed flow for each approach Docker build: ( Outside of Openshift) ============================== Eclipse —> Git —> Jenkins to build and create artifacts —> Jenkins Docker Plug-in to create image and push to corporate repo —> oc import-image and oc deploy —latest Basically build & Image creation happening out side of Openshift. OpenShift native: ============== Eclipse —> GIT —> Jenkins to build artifacts —> OC Binary deploy by CI/CD tool against each app as CI/CD has admin access to each project We have 2 choices here a) binary build for each life cycle b) build for dev life cycle and promote using docker tag and push to other life cycles. Option B make more sense naturally This approach using native openshift for build and deployments. Also using openshift internal registries to store final build images for each life cycle. Can you comment on each pros and cons? From scaling ( hundred thousand deployments) as well as easy to operate and maintain. Whatever approach it should be repeatable and reliable without errors since we will automate everything as part of CI/CD pipeline. Thanks in advance and appreciated feedback -- SrinivasKotaru _______________________________________________ users mailing list users@lists.openshift.redhat.com https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openshift.redhat.com_openshiftmm_listinfo_users&d=CwICAg&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=8IlWeJZqFtf8Tvx1PDV9NsLfM_M0oNfzEXXNp-tpx74&m=lwMOrMH5uQuS0bXtBW5_dMK5rygsmaJRq1XyBxGrjm0&s=--Mau5gkyzLBfAg_YMyH1xFRPx739yA31PmjW9CZcDc&e=
_______________________________________________ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
