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.
Related
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 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.
I defined a template (let's call it template.yaml) with a service, deploymentconfig, buildconfig and imagestream, applied it with oc apply -f template.yaml and ran oc new-app app-name to create new app from the template. What the app basically does is to build a Node.js application with S2I, write it to a new ImageStream and deploy it to a pod with the necessary service exposed.
Now I've decided to make some changes to the template and have applied it on OpenShift. How do I go about ensuring that all resources in the said template also get reconfigured without having to delete all resources associated with that template and recreating it again?
I think the template is only used to create the related resource first time. Even though you modify the template, it's not associated with created resources. So you should recreate or modify each resource that is modified.
But you can modify simply all resources created by template using the following cmd.
# oc apply -f template_modified.yaml | oc replace -f -
I hope it help you
The correct command turned out to be:
$ oc apply -f template_modified.yaml
$ oc process -f template_modified.yaml | oc replace -f -
That worked for me on OpenShift 3.9.
I'm creating a new-app based on an image stream that corresponds to a docker image in a private OpenShift docker registry. The command is:
oc new-app mynamespace/my-image:latest -n=my-project
Question 1: Does this command automatically create a deployment configuration (dc) that can be referrenced as dc/my-image? Is this deployment configuration associated with my-project?
Question 2: What is the oc command to create a deployment configuration? The OpenShift developer guide has a section titled Creating a Deployment Configuration, but surprisingly it does not say how to create a DC or give any examples. It just shows a JSON structure and says DCs can be managed with the oc command.
Yes, your command will create stuff in the specified project. You can check what objects are created using the oc get command. i.e. to check what DCs you have, you'd do oc get dc or oc get deploymentconfigs.
Other useful commands are oc describe - similar to get but more information. oc status -v - see more broad information about project including warnings and errors.
You create DC and any other resource types using the oc create command. e.g. you copy the example DC off the URL you link to and put it into a file. Finally you do oc create -f mydc.yaml. Both YAML and JSON are supported.
As you see some commands can create DCs by themselves without you providing them with YAML or JSON. You can later modify existing resources with oc edit service/my-app. There is the oc patch command suitable for scripting.
You can see existing resource YAML doing oc get dc/myds -o yaml. Same with any other resource. Keep in mind you are presently using the desired project or use the -n option as you are doing in your example.
Not that hard once you understand some basics and learn to use the oc describe and oc logs command to debug issues with your images/pods. e.g. oc describe pod/my-app-1-asdfg, oc logs my-app-1-asdfg, oc logs -f dc/my-app.
HTH