Hi Graham,

If the image was designed to be configured using environment variables or
configuration files that can be provided as volumes, yes you don't need a
custom image. But from Dan message I expect more extensive customizations
which would become cumbersome.

And the idea of forcing the image to run a different command than its
entrypoint, them get more files from a volume, to customize the image or
compensate for deficiencies in the original entrypoint command, seem also
cumbersome to me. You are making extensive changes each time you start the
container (to it's ephemeral read/write layer). I don't see the advantage
compared to just creating a child image with an extra layer that has the
customizations.


[]s, Fernando Lozano



On Wed, Feb 21, 2018 at 7:40 PM, Graham Dumpleton <gdump...@redhat.com>
wrote:

> Another example of where this can be useful is where the primary process
> in the container doesn't do what is required of process ID 1. That is, reap
> zombie processes. If that becomes an issue you can use a run script wrapper
> like:
>
> #!/bin/sh
>
> trap 'kill -TERM $PID' TERM INT
>
> /usr/libexec/s2i/run &
>
> PID=$!
> wait $PID
> trap - TERM INT
> wait $PID
> STATUS=$?
> exit $STATUS
>
> This simple alternative to a mini init process manager such as tini, will
> work fine in many cases.
>
> Replace /usr/libexec/s2i/run with actual program to run.
>
> Graham
>
> On 22 Feb 2018, at 9:33 am, Graham Dumpleton <gdump...@redhat.com> wrote:
>
> Badly worded perhaps.
>
> In some cases you don't have the ability to modify an existing image with
> the application in it, plus you may not want to create a new custom image
> as a layer on top. In those cases, if all you need to do is some minor
> tweaks to config prior to the application starting in the container you can
> use the configmap trick as described. It will work so long as the config
> files you need to change can be modified as the user the container is run
> as.
>
> So you can do:
>
>     oc create configmap blog-run-script --from-file=run
>
>     oc set volume dc/blog --add --type=configmap \
>         --configmap-name=blog-run-script \
>         --mount-path=/opt/app-root/scripts
>
>     oc patch dc/blog --type=json --patch \
>         '[{"op":"add",
>            "path":"/spec/template/spec/containers/0/command",
>            "value":["bash","/opt/app-root/scripts/run"]}]'
>
> So the 'run' script makes the changes and then executes original command
> to start the application in the container.
>
> Graham
>
> On 22 Feb 2018, at 9:22 am, Fernando Lozano <floz...@redhat.com> wrote:
>
> Hi Graham,
>
> This doesn't make sense to me:
>
> >  3. If don't want to create a new custom image.
>
> If you wanna run your application in a container you have to create a
> custom image with the application. There's no way around, because container
> images are immutable. You can only choose how you will build your custom
> image. This is the way containers are supposed to work, with or without
> OpenShift.
>
>
> []s, Fernando Lozano
>
>
> On Wed, Feb 21, 2018 at 6:15 PM, Graham Dumpleton <gdump...@redhat.com>
> wrote:
>
>>
>>
>> On 22 Feb 2018, at 3:21 am, Fernando Lozano <floz...@redhat.com> wrote:
>>
>> Hi Dan,
>>
>> As you learned, lifecycle hooks were not made to change anything inside a
>> container image. Remember that container images are, by design, immutable.
>> It looks you want to build a custom container image that includes your
>> customizations to the wildfly configs plus your application. There are two
>> ways to accomplish that with OpenShift:
>>
>> 1. Create a Dockerfile that uses the standard wildfly container image as
>> the parent, and adds your customization.
>>
>> 2. Use the OpenShift source-to-image (s2i) process to add configurations
>> and your application. See the OpenShift docs about the wildfly s2i builder
>> image for details, this is easier than using a Dockerfile. The standard s2i
>> processes builds the application from sources, but it also supports feeding
>> an application war/ear.
>>
>>
>> 3. If don't want to create a new custom image, but want to add additional
>> actions before application started in the container, mount a shell script
>> into the container from a config map. Override the command for the pod to
>> run your script mounted from config map. Do you work in the script, with
>> your script then doing an exec on the original command for the application.
>>
>> Graham
>>
>> []s, Fernando Lozano
>>
>>
>> On Wed, Feb 21, 2018 at 9:43 AM, Dan Pungă <dan.pu...@gmail.com> wrote:
>>
>>> Hello all!
>>>
>>> Trying to build an OShift configuration for running a Java app with a
>>> Wildfly server.
>>> I've setup this with ChainBuilds where the app's artifacts are combined
>>> with a runtime image of Wildfly.
>>>
>>> For this particular app, however, I need to do some configuration on the
>>> Wildfly environment, so that the app is properly deployed and works.
>>> - update a server module (grabbing the contents from the web and copying
>>> them in the right location inside Wildfly)
>>> - add system properties and some other configuration to Wildfly's
>>> standalone.xml configuration file
>>> - create some directory structure
>>>
>>> I've tried to run all this with the Recreate deployment starategy and as
>>> a mid-hook procedure (so the previous deployment pod is scaled down), but
>>> all these changes aren't reflected in the actual(new) deployment pod.
>>>
>>> Taking a closer look at the docs, I've found this line "Pod-based
>>> lifecycle hooks execute hook code in a new pod derived from the template in
>>> a deployment configuration."
>>> So whatever I'm doing in my hook, is actually done in a different pod,
>>> the hook pod, and not in the actual deployment pod. Did I understand this
>>> correctly?
>>> If so, how does the injection work here? Does it have to do with the
>>> fact that the deployment *has to have* persistent volumes? So the hooks
>>> actually do changes inside a volume that will be mounted with the
>>> deployment pod too...
>>>
>>> Thank you!
>>>
>>>
>>> _______________________________________________
>>> users mailing list
>>> users@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>
>>>
>> _______________________________________________
>> users mailing list
>> users@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>>
>>
>
>
>
_______________________________________________
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Reply via email to