On Fri, Aug 26, 2016 at 6:10 PM, Ravi Kapoor <ravikapoor...@gmail.com> wrote:
> > Ben, > > Thank you so much for taking the time to explain. This is very helpful. > If I may, I have a few followup questions: > > > That is not a great approach to running code. It's fine for > development, but you really want to be producing immutable images that a > developer can hand to QE has tested it, they can hand that exact same image > to prod, and there's no risk that pieces have changed. > > Q1: It seems like Lyft uses the approach I was mentioning i.e. inject > code into dockers rather than copy code inside dockers (ref: > https://youtu.be/iC2T3gJsB0g?t=595). In this approach there are only two > elements - the image (which will not change) and the code build/tag which > will also not change. So what else can change? > > > running things in that way means you need to get both the image and > your class files into paths on any machine where the image is going to be > run, and then specify that mount path correctly > > Q2: I would think that openshift has a mechanism to pull files from git to > a temp folder and way to volume mount that temp folder into any container > it runs.Volume mounts are very basic feature of dockers and I am hoping > they are somehow workable with openshift. Are they not? Don't we need them > for lets say database dockers? Lets say a mongodb container is running, it > is writing data to a volume mounted disk. If container crashes, is > openshift able to start a new container with previous saved data? > and just to answer the last part of this explicitly: yes, persistent storage is possible with openshift through persistent volumes, the persistent volume will be re-mounted to the container when it restarts and the previous data will be present. My previous email included a link to docs on persistent volumes for more info. > > > Q3: Even if you disagree, I would still like to know (if nothing else then > for learning/education) about how to run external images with volume mounts > and other parameters being passed into the image. I am having very hard > time finding this. > > regards > Ravi > > > On Fri, Aug 26, 2016 at 10:29 AM, Ben Parees <bpar...@redhat.com> wrote: > >> >> >> On Fri, Aug 26, 2016 at 1:07 PM, Ravi <ravikapoor...@gmail.com> wrote: >> >>> >>> So I am trying to use openshift to manage our dockers. >>> >>> First problem I am facing is that most of documentation and image >>> templates seem to be about S2I. We are >> >> >> When it comes to building images, openshift supports basically 4 >> approaches, in descending order of recommendation and increasing order of >> flexibility: >> >> 1) s2i (you supply source and pick a builder image, we build a new >> application image and push it somewhere) >> 2) docker-type builds (you supply the dockerfile and content, we run >> docker build for you and push the image somewhere) >> 3) custom (you supply an image, we'll run that image, it can do whatever >> it wants to "build" something and push it somewhere, whether that something >> is an image, jar file, etc) >> 4) build your images externally on your own infrastructure and just use >> openshift to run them. >> >> The first (3) of those are discussed here: >> https://docs.openshift.org/latest/architecture/core_concepts >> /builds_and_image_streams.html#builds >> >> >> >>> considering a continuous builds for multiple projects and building an >>> image every 1 hour for multiple projects would create total 20GB images >>> every day. >>> >> >> I'm not sure how this statement relates to s2i. Do yo have a specific >> concern about s2i with respect to creating these images? Openshift does >> offer image pruning to help deal with the number of images you sound like >> you'll be creating, if you're interested in that. >> >> >> >>> >>> Q1: Is this right way of thinking? Since today most companies are doing >>> CI, this should be a common problem. Why is S2I considered impressive >>> feature? >>> >> >> S2I really has little to do with CI/CD. S2I is one way to produce >> docker images, there are others as I listed above. Your CI flow is going >> to be something like: >> >> 1) change source >> 2) build that source into an image (in whatever way you want, s2i is one >> mechanism) >> 3) test the new image >> 4) push the new image into production >> >> The advantages to using s2i are not about how it specifically works well >> with CI, but rather with the advantages it offers around building images in >> a quick, secure, convenient way, as described here: >> >> https://docs.openshift.org/latest/architecture/core_concepts >> /builds_and_image_streams.html#source-build >> >> >> >> >>> >>> So, I am trying to use off the shelf images and inject code/conf into >>> them. I know how to do this from docker command line (example: docker run >>> --rm -it -v /my/host/folder:/usr/src/myapp -w /usr/src/myapp >>> openjdk:8-jre-alpine java myClass ) >>> >> >> That is not a great approach to running code. It's fine for >> development, but you really want to be producing immutable images that a >> developer can hand to QE has tested it, they can hand that exact same image >> to prod, and there's no risk that pieces have changed. >> >> Also running things in that way means you need to get both the image and >> your class files into paths on any machine where the image is going to be >> run, and then specify that mount path correctly. It's not a scalable >> model. You want to build runnable images, not images that need the >> application side-loaded via a mount. >> >> >> >> >>> >>> Q2: How do I configure exact same command from openshift? I will need to >>> do following steps >>> >> >> You shouldn't. Strictly speaking you can, via pod mount definitions and >> hostpath volume definitions, but it's not the right way to think about >> creating and running images in a clustered environment. >> >> >> >>> 1. Jenkins is pushing compiled jar files to git repository. First step >>> will be to pull the files down. >>> 2. I may have to unzip some files (in case it is bunch of configurations >>> etc.) >>> 3. Openshift should use docker run to create containers. >>> >> >> Assuming you want to continue building jars via jenkins and pushing them >> somewhere (doesn't have to be git), i'd suggest the following flow: >> >> 1) jenkins builds jar and pushes it somewhere >> 2) an s2i(or docker) build in openshift pulls from that somewhere (either >> it's pulling the git source that includes the jar, or you can write your >> own assemble script which pulls the jar from a nexus repo(or a dockerfile >> which does so) or some other location. This is discussed here: >> https://docs.openshift.org/latest/dev_guide/builds.html#usin >> g-external-artifacts) >> >> You can also do binary builds which don't require you put the content in >> a git repo: >> https://docs.openshift.org/latest/dev_guide/builds.html#binary-source >> >> in which case the jenkins job would build the jar locally and then invoke >> "oc start-build yourbuild --from-file your.jar" >> >> >> 3) the image will get pushed to a docker registry as part of the build >> 4) the image gets deployed on openshift, it is fully self-contained and >> does not need any external mounts. It can scale up and move between host >> nodes without any adminstrative maintenance. >> >> Hope that helps. >> >> >> >> >>> >>> thanks so much for help >>> Ravi >>> >>> _______________________________________________ >>> users mailing list >>> users@lists.openshift.redhat.com >>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users >>> >> >> >> >> -- >> Ben Parees | OpenShift >> >> > -- Ben Parees | OpenShift
_______________________________________________ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
