----- On Mar 22, 2016, at 7:05 AM, Ben Parees <[email protected]> wrote:
On Tue, Mar 22, 2016 at 12:58 AM, Dale Bewley < [email protected] > wrote: BQ_BEGIN I'm trying to understand best practices for creating and maintaining builder images. For example, I would like to start with this repo https://github.com/openshift/sti-python/blob/master/2.7/ and customize the Dockerfile to the include the Oracle instantclient libraries. So first off, rather than customizing the dockerfile and building the whole image over again, you should do: FROM centos/python-27-centos7 RUN yum install oracle-instantclient # or whatever BQ_END Do you mean `FROM openshift/python-27-centos7` ? This is the approach I'm taking at the moment. Does it look sane? 1. Clone https://github.com/openshift/sti-python/ and make it my own by changing the 2.7/Dockerfile to look like this: ``` FROM openshift/python-27-centos7 # This image provides a Python 2.7 environment you can use to run your Python # applications. MAINTAINER Admin <[email protected]> EXPOSE 8080 ENV PYTHON_VERSION=2.7 \ PATH=$HOME/.local/bin/:$PATH LABEL io.k8s.description="Platform for building and running Python 2.7 applications with Oracle Support" \ io.k8s.display-name="Python 2.7 Oracle" \ io.openshift.expose-services="8080:http" \ io.openshift.tags="builder,python,python27,rh-python27,oracle,example" USER 0 # Setup oracle environment for Example # RUN yum install oracle things # Install python support for Oracle RUN /opt/rh/python27/root/usr/bin/pip install cx_Oracle # Copy the S2I scripts from the specific language image to $STI_SCRIPTS_PATH COPY ./s2i/bin/ $STI_SCRIPTS_PATH # Each language image can have 'contrib' a directory with extra files needed to # run and build the applications. COPY ./contrib/ /opt/app-root # In order to drop the root user, we have to make some directories world # writable as OpenShift default security model is to run the container under # random UID. RUN chown -R 1001:0 /opt/app-root && chmod -R og+rwx /opt/app-root USER 1001 # Set the default CMD to print the usage of the language image CMD $STI_SCRIPTS_PATH/usage ``` 2. Create a `example` project and give `system:authenticated` group view and pull permissions. ``` oadm policy add-role-to-group system:image-puller system:authenticated -n example oadm policy add-role-to-group view system:authenticated -n example ``` 3. In the example project create a imagestream like this ``` apiVersion: v1 kind: ImageStream metadata: annotations: name: python-27-centos7 spec: dockerImageRepository: example/python-27-centos7 ``` 4. In the example project c reate a buildconfig like this ``` apiVersion : v1 kind : BuildConfig metadata : name : python-27-centos7 annotations : description : Defines how to build python-27-centos7 builder image spec : output : to : kind : ImageStreamTag name : python-27-centos7:latest source : git : uri : http://gitlab.example.com/openshift/sti-python.git type : Git contextDir : " 2.7" strategy : type : Docker dockerStrategy : { } triggers : - type : " imagechange" imageChange : from : kind : " ImageStreamTag" name : " openshift/python-27-centos7:latest" ``` 5. In the example project `oc start-build python-27-centos7` 6. Create a template to use example/python-27-centos7 + developer's python app git repo. BQ_BEGIN That way you are just layering on top of the existing s2i image. BQ_BEGIN As a test with fewer dependencies I used s2i https://github.com/openshift/source-to-image/releases/ and referred to openshift/sti-php to bootstrap a simple Dockerfile https://gist.github.com/dlbewley/88bce324daf700d49bf0 for creating static-content sites. I then used Docker build strategy `oc new-app http://gitlab/static-builder.git` to create an app from the git repo. BQ_END you can use "oc new-build" for cases where you just want a buildconfig and no deploymentconfig, such as this one where the resulting image isn't really deployable. BQ_BEGIN OpenShift built the image called `static-builder` (and an app with no real content) in my project. I was able to utilize that with `oc new-app builder-image~ http://gitlab/static-site.git` . BQ_END BQ_BEGIN I like that I can use a web hook to rebuild my builder image when I update the static-builder.git repo, but I'm wondering what the "proper" method is. Should I expose my registry, build images externally, then push the builder images to it? That feels too manual, and how do I ensure the image is always using the latest upstream `openshift/sti-foo` image each time a user creates a new app from my `static-builder` image? BQ_END I'm not sure why you're asking about building the images externally since you've successfully built the image within openshift already? I'm also not sure what you mean about using the latest openshift/sti-foo image. The normal flow for what you're doing would be: 1) create an imagestream for the image you are deriving from (base-centos7 in this case, but again i'd recommend you start with an image further down the chain, depending on what you can reuse) 2) create a buildconfig that uses (1) as the base image and produces your new builder image. It will push this to an imagestream as well. 3) create a buildconfig that uses the imagestream from (2) to build an application image. With the default imagechange triggers, any time (2) changes, (3) will be rebuilt. Because (1) is based on an external docker image (not one in the openshift registry), you will not get automatic notifications when the docker image backing (1) changes, so you will need to periodically run "oc import-image" to refresh the imagestream. (you can also explicitly enable scheduled import by editing the imagestream). If you also want to rebuilt (2) when you've updated the dockerfile/git content that is part of (2), then you can do as you discovered: setup the github webook, which requires your api server(but nothing else) be reachable by github. BQ_BEGIN Thanks _______________________________________________ users mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/users BQ_END -- Ben Parees | OpenShift BQ_END
_______________________________________________ users mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/users
