I created a project on OpenShift 4.2 with an ImageStream that is pulling an Image from Quay.io:
oc new-project xxx-imagestream
oc import-image is:1.0 --from quay.io/xxx/myimage:latest --confirm --reference-policy local
Now I create a new project to host an app based on that ImageStream
oc new-project xxx-app
oc new-app --name myapp -i xxx-imagestream/is:1.0
The app is built and I can use it by exposing it. (But no Build or BuildConfig is created. Why???)
Now I update the image on Quay.io with a new version, and import the new version into the xxx-imagestream project:
oc import-image is:2.0 --from quay.io/xxx/myimage:latest --confirm --reference-policy local
The question is: how do I update my app (myapp)? In other words, how can I launch a new build of "myapp" based on the updated ImageStream?
(But no Build or BuildConfig is created. Why???)
A BuildConfig is only created when you use the "Source to Image" (S2I) functionality and is only needed when you want to create a container image from source. In your case, the image already exists, so there is no need to build anything. The only thing that oc new-app will do is deploy your existing image, there is no build necessary.
The question is: how do I update my app (myapp)? In other words, how can I launch a new build of "myapp" based on the updated ImageStream?
You are looking for "Deployment triggers", specifically the "ImageChange deployment trigger". The ImageChange trigger results in a new ReplicationController whenever the content of an imagestreamtag changes (when a new version of the image is pushed).
On a side-note, you can also periodically automate the importing of new image versions in your ImageStreams (see documentation).
The build starts automatically if your image stream has
--reference-policy source
In that case, it is correct to update the image stream using
oc -import-image [...]
To update a "local" ImageStream, instead of
oc import-image is:2.0 --from quay.io/xxx/myimage:latest --confirm --reference-policy local
you should update the existing local ImageStream tag
oc tag quay.io/xxx/myimage:latest is:2.0 --reference-policy local
This command automatically triggers a new deployment of your app.
Add this to your deploymentConfig
triggers:
- type: ConfigChange
- imageChangeParams:
automatic: true
containerNames:
- <your-container-name>
from:
kind: ImageStreamTag
name: '<image_name>:latest'
namespace: <your-namespace>
type: ImageChange
Related
I would like to perform the following script in our test-environment to deploy our application in OpenShift 4.8.
oc apply -f deployment-config.yaml
oc rollout latest dc/my-application
The trigger in deployment config is ConfigChange. If e.g. an environment variable has changed in deployment config oc apply -f deployment-config.yaml will trigger a rollout.
The deployment config uses snapshot as image. We don't have a version number of our snapshot which means that a new snapshot might need to be deployed even though deployment config has not been changed. Thats why we use oc rollout latest dc/my-application.
image: "<repo-url>/my-application:snapshot"
imagePullPolicy: Always
The problem is that sometimes both oc apply -f deployment-config.yaml and oc rollout latest dc/my-application will trigger a rollout.
Is there a way to do oc apply -f deployment-config.yaml without triggering a rollout? Or do you se another solution?
As of Deployment triggers you need to define the trigger as empty field. If you just remove the trigger, a config change trigger will be added by default.
If no triggers are defined on a DeploymentConfig object, a config change trigger is added by default. If triggers are defined as an empty field, deployments must be started manually.
oc new-app always creates a DeploymentConfig. Is there an option to create a Deployment instead of a DeploymentConfig?
Why? DeploymentConfig is a proprietary legacy Red Hat only resource kind. I would prefer a modern cross platform industry standard Deployment.
oc new-app always creates a DeploymentConfig. Is there an option to create a Deployment instead of a DeploymentConfig?
Current versions of oc have been creating Deployments for quite some time now:
$ oc new-app --docker-image=<IMAGE> --name=my-application
--> Found container image [..]
* An image stream tag will be created as "my-application:latest" that will track this image
--> Creating resources ...
imagestream.image.openshift.io "my-application" created
deployment.apps "my-application" created
service "my-application" created
--> Success
Application is not exposed. You can expose services to the outside world by executing one or more of the commands below:
'oc expose service/my-application'
Run 'oc status' to view your app.
$ oc get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
my-application 1/1 1 1 7s
$ oc get deploymentconfig
No resources found in simon namespace.
So you should update your oc client as you seem to be using an old version (my output above is with a 4.6 client).
The old behaviour of creating a DeploymentConfig can still be forced by using the
--as-deployment-config option:
$ oc new-app --docker-image=<IMAGE> --name=my-application --as-deployment-config
Note that DeploymentConfigs still have their place if you want to use features like triggers, automatic rollback, lifecycle hooks or custom strategies (DeploymentConfigs-specific features)
Does anyone know how to get an AspNetCore 3.0 image for free my minishift project.
Thank you in advance.
I am not sure if I understood your question correctly, but Microsofts ASP.NET Core Runtime container image is available here: https://hub.docker.com/_/microsoft-dotnet-core-aspnet/
docker pull mcr.microsoft.com/dotnet/core/aspnet:3.1
Getting the image to run on OpenShift is a bit tricky, as the container image uses Port 80. So to deploy the sample application, we need to add the extra steps to create a ServiceAccount and assign the SCC:
# Deploy the DeploymentConfig
oc new-app --name aspnetcore-sample mcr.microsoft.com/dotnet/core/samples:aspnetapp
# Create a ServiceAccount, give it the "anyuid" SCC and assign it to the DeploymentConfig
oc create serviceaccount aspnetcore-sample-sa
oc adm policy add-scc-to-user anyuid -z aspnetcore-sample-sa
oc set serviceaccount dc aspnetcore-sample aspnetcore-sample-sa
# Expose the application to the outside world via a route
oc expose dc aspnetcore-sample --port=80
oc expose service aspnetcore-sample
# See the route with the following command
oc get route
I have a project/namespace in Openshift 3.9. It has one Mysql db pod, the credentials details are stored as secrets.
While deploying my Springboot application, in Openshift UI, I change the Deployment Configuration to map the dynamic variables from my APP to Mysql secrets.
Now I want to automate this step, and how do I mention/pass these secrets while using the oc new-app cmd. I am using below command, but not sure on how to pass/map variables to secrets.
oc new-app redhat-openjdk18-openshift~https://github.com/xyzasdkjasnda/openshift-mysql
Somewhere I saw a workaround like below,
oc new-app
redhat-openjdk18-openshift~https://github.com/xyzasdkjasnda/openshift-mysql
| jq '.items[] | select(.kind == "DeploymentConfig") |
.spec.template.spec.containers[0].env +=
[{"name":"db_name","valueFrom":{"secretKeyRef":{"key":"database-name","name":"mysql"}}},{"name":"db_username","valueFrom":{"secretKeyRef":{"key":"database-user","name":"mysql"}}},{"name":"db_password","valueFrom":{"secretKeyRef":{"key":"database-password","name":"mysql"}}}]'
| \
oc apply --filename -
While oc new-app seems convenient, it usually is preferred to explicitly create a DeploymentConfig (or Deployment) file and check it into a code repo; use oc create -f <deployment-filename> to create the actual object in OpenShift.
See Example #3 here for how to populate environment variables with values from Secrets - that is what the "workaround" does.
Alternatively, you can still use oc new-app to create a new application, including building it from source code, which will create the DeploymentConfig you can then edit to add the environment variables from Secrets configuration.
I am trying to create a cicd pipeline with openshift. Initially, when creating the application using 'oc new-app' command, it automatically triggers the build. How i need to disable the initial build other than deleting or cancel the build?
How i need to disable the initial build other than deleting or cancel the build?
oc new-app can not prevent the initial build.
It had discussed here: https://github.com/openshift/origin/issues/15429
Unfortunately it does not implement now.
But, you can prevent initial build as removing all triggers from buildConfig by modifying yaml of buildConfig manually.
First export oc new-app as yaml format.
# oc new-app --name=test \
centos/ruby-25-centos7~https://github.com/sclorg/ruby-ex.git -o yaml --dry-run > test.yml
Remove all triggers as changing the configuration to triggers: [].
strategy:
sourceStrategy:
from:
kind: ImageStreamTag
name: ruby-25-centos7:latest
type: Source
triggers: []
After modifying, create resources using oc create -f.
# oc create -f test.yml
imagestream.image.openshift.io/ruby-25-centos7 created
imagestream.image.openshift.io/ruby-ex created
buildconfig.build.openshift.io/ruby-ex created
deploymentconfig.apps.openshift.io/ruby-ex created
service/ruby-ex created
The build does not run until you run oc start-build <bc name> and oc rollout latest dc/<dc name>.
I hope this use case is helpful for you.