With oc new-app command (source strategy) several objects are created but not an horizontal pod autoscaler object.
Can it be automated that after the new-app command an horizontal pod autoscaler is created? Or should I do it manually?
Thank you.
You should use Template[0] or custom script[1] to automate the process, because autoscaler is required deployment controller which is configured resources section to calculate the resource usage from autoscaler.
[0]Templates
[1] For example,
#!/bin/bash
oc new-app httpd &&
oc set resources dc/httpd --requests=cpu=100m &&
oc autoscale dc/httpd --min 1 --max 10 --cpu-percent=80
exit $?
Related
Openshift does not allow to run containers as root, but you can do this by creating a service account:
oc adm policy add-scc-to-user anyuid -z useroot
and then patching the deployment configuration, this will consequently deploy a new replication controller version with the new changes, is it possible to create the service account and include it in the following command:
oc new-app --name=test --docker-image=myregistry.com/test:latest
and have the service Account name included in the above command to avoid having a new version of the app or if there's any other possibility to foresee this root permission error and decrease the security for the pod to run as root without patching or redeploy the app
Will and Graham has already provided great comments for you,
so I suggest additional practical details of them as follows.
If you grant anyuid scc to default ServiceAccount before oc new-app, the test pods are going to run as root permission without version change.
# oc adm policy add-scc-to-user anyuid -z default
# oc new-app --name=test --docker-image=myregistry.com/test:latest
# oc rollout history dc/test
deploymentconfigs "test"
REVISION STATUS CAUSE
1 Complete config change
# oc rsh dc/test id
uid=0(root) gid=0(root) groups=0(root)
OR
If you need to specify the custom ServiceAccount name, you can extract oc new-app yaml and create resources after add serviceAccountName: useroot element to it. These steps also do not change the deployment version.
# oc create sa useroot
# oc adm policy add-scc-to-user anyuid -z useroot
# oc new-app --name=test --docker-image=myregistry.com/test:latest -o yaml --dry-run > test.yml
# vim test.yml
apiVersion: v1
items:
- apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
...
spec:
...
template:
spec:
serviceAccountName: useroot
...
# oc create -f ./test.yml
imagestream.image.openshift.io/test created
deploymentconfig.apps.openshift.io/test created
service/test created
# oc rollout history dc/test
deploymentconfigs "test"
REVISION STATUS CAUSE
1 Complete config change
# oc rsh dc/test id
uid=0(root) gid=0(root) groups=0(root)
I need to automate monitoring log of pods of an app
Monitoring a pod's log can be done using oc CLI
oc log -f my-app-5-43j
However, the pod's name changes dynamically over the deployments. If I want to automate the monitoring, like running a cron job, continually tailing the log even after another deployment, how should I do?
Will Gordon already commented solution, so I provide more practical usage for your understanding.
If you deploy your pod using deploymentConfig, daemonSet and so on, you can see logs of the pod without specifying a pod name as follows.
# oc logs -f dc/<your deploymentConfig name>
# oc logs -f ds/<your daemonset name>
Or you can get first pod name dynamically using jsonpath output option to see log.
# oc logs -f $(oc get pod -o jsonpath='{.items[0].metadata.name}')
If you can specify the pod with a specific label, you can use -l option either.
# oc logs -f $(oc get pod -l app=database -o jsonpath='{.items[0].metadata.name}')
I'm trying to setup artifactory on Openshift Online 3 Starter using docker image docker.bintray.io/jfrog/artifactory-oss:latestfrom here
But when deploying I got an error
I tried to create artifactory user by command oc create serviceaccount artifactory and then oc adm policy add-scc-to-user anyuid -z artifactory but has another error:
Error from server (Forbidden): User "xxxx" cannot get securitycontextconstraints at the cluster scope
You need to be cluster admin in order to be able to run:
oc adm policy add-scc-to-user anyuid -z artifactory
This is because it is granting the right to run things as any user ID, including root. This is something that you as a normal user aren't allowed to do.
Further, in OpenShift Online you can only run things in the user ID range you are assigned. You cannot override that, nor will you be granted additional privileges.
You would need to find a version of the image which doesn't require it be run as root and which can run as an arbitrary user ID.
I am struggle with the scc's within OpenShift. All my pods are made with scc: restricted. But now I want some pods in privileged mode.
I tried with this command:
$ oc edit scc privileged
And add serviceaccount and namespace
Als tried to make a new scc with users:
$ oc create -f scc.yaml
But all new pods are still create with scc: restricted :-(
You want to be using oc adm policy add-role-to-user -z default somerole. The question is why you would want to do that. Running containers with root or other elevated privileges is usually a bad idea and unless you have cluster admin access for the OpenShift cluster, you cannot enable such privileges. The need to run with extra privileges is generally indicative of a poorly constructed image. Images should be designed to run as an arbitrary non root user.
I am experimenting with openshift/minishift, I find myself having to run:
oc edit scc privileged
and add:
- system:serviceaccount:default:router
So I can expose the pods. Is there a way to do it in a script?
I know oc adm have some command for policy manipulation but I can't figure out how to add this line.
You can achieve it using oc patch command and with type json. The snippet below will add a new item to array before 0th element. You can try it out with a fake "bla" value etc.
oc patch scc privileged --type=json -p '[{"op": "add", "path": "/users/0", "value":"system:serviceaccount:default:router"}]'
The --type=json will interpret the provided patch as jsonpatch operation. Unfortunately oc patch --help doesn't provide any example for json patch type. Luckily example usage can be found in kubernetes docs: kubectl patch
I have found an example piping to sed Here and adapted it to ruby so I can easily edit the data structure.
oc get scc privileged -o json |\
ruby -rjson -e 'i = JSON.load(STDIN.read); i["users"].push "system:serviceaccount:default:router"; puts i.to_json ' |\
oc replace scc -f -
Here is quick and dirty script to get started with minishift
The easiest way to add and remove users to SCCs from the command line is using the oc adm policy commands:
oc adm policy add-scc-to-user <scc_name> <user_name>
For more info, see this section.
So for your specific use-case, it would be:
oc adm policy add-scc-to-user privileged system:serviceaccount:default:router
I'm surprised its needed though. I use "oc cluster up" normally, but testing with recent minishift, its already added out of the box:
$ minishift start
$ eval $(minishift oc-env)
$ oc login -u system:admin
$ oc get scc privileged -o yaml | grep system:serviceaccount:default:router
- system:serviceaccount:default:router
$ minishift version
minishift v1.14.0+1ec5877
$ oc version
openshift v3.7.1+a8deba5-34