CODEWITHSUNDEEP
openshiftgrafana
Marek
Marek

Reputation: 1

altering an Openshift pole automatically on deployment

I'm using a provided Openshift PaaS deployment Grafana app image.

I'd like to add a plugin to that Grafana it is done by adding certain files to the file system or invoking a grafana-cli command.

I managed to do it manually with a single pole by accessing it through the oc CLI. What I don't know is how to make it persistent. I would like it to by applied whenever an Openshift pole is instantiated. I found no other way than providing a custom image for that.

Is there a supported way of adding files to an existing predefined image? Or invoking a command on a pole after deployment? I tried the post deployment hook but it appears that the filesystem is not there yet (or I don't know how to use this hook)

Upvotes: 0

Views: 117

Answers (1)

Graham Dumpleton
Graham Dumpleton

Reputation: 58523

A post deployment life cycle hook runs in its own container, with its own file system, not the container of the application. You want to look at a postStart hook.

$ oc explain dc.spec.template.spec.containers.lifecycle
RESOURCE: lifecycle <Object>

DESCRIPTION:
     Actions that the management system should take in response to container
     lifecycle events. Cannot be updated.

    Lifecycle describes actions that the management system should take in response to container lifecycle events. For the PostStart and PreStop lifecycle handlers, management of the container blocks until the action is complete, unless the container process fails, in which case the handler is aborted.

FIELDS:
   postStart    <Object>
     PostStart is called immediately after a container is created. If the
     handler fails, the container is terminated and restarted according to its
     restart policy. Other management of the container blocks until the hook
     completes. More info:
     http://kubernetes.io/docs/user-guide/container-environment#hook-details

   preStop  <Object>
     PreStop is called immediately before a container is terminated. The
     container is terminated after the handler completes. The reason for
     termination is passed to the handler. Regardless of the outcome of the
     handler, the container is eventually terminated. Other management of the
     container blocks until the hook completes. More info:
     http://kubernetes.io/docs/user-guide/container-environment#hook-details

Upvotes: 0

Related Questions