oc new-app --docker-image vs oc create deployment image

[TheHero]

So I am studying the ex280, and in the material most of the time they use oc new-app --docker-image quay_url except in one exercise they used following:

Create a new application named hello using the container located at quay.io/redhattraining/hello-world-nginx:v1.0

oc create deployment hello --image quay.io/redhattraining/hello-world-nginx:v1.0

so the concern here, how to know when to use the oc create deployment rather than oc new-app? Note I tried the command "oc new-app --name  hello --docker-image quay.io/redhattraining/hello-world-nginx:v1.0" but it didnt work.

[jordisola]

Hi TheHero!

The main difference between using "oc new-app" and "oc create deployment" is the number of resources created.

"oc create deployment" creates a "DeploymentConfiguration" resource, getting the image from the registry (quay.io in this case) and deploying as needed (i.e. one replica by default).

"oc new-app" creates a bunch of resources. In this case, as you are providing an image, it creates the "DeploymentConfiguration", the "ImageStream" and the "Service" needed to develop and manage the application itself (note the associated route is not created by default). 

Other "oc new-app" variants may create more resources (i.e. if the source code is provided, "BuildConfig" resources are created).

So, responding to your question, using "oc new-app" is more common and useful for creating a new application from source code or images. Use "oc create deployment" if you need to update an existing application with new deployments, or need fine-grained control on your application resources.

Hope that helps.

KR

Jordi Sola

[TheHero]

thanks a lot for the great explanation :).

So correct me if I am wrong, I would assume they should be more accurate with the question phrase, because based on the question statement  "Create a new application named hello using the container located at quay.io/redhattraining/hello-world-nginx:v1.0"  the first thing came up in my mind to use "oc new-app" command, but it didnt work, they should mention "create deployment configuration"  rather  "create new app" in the question.

Again thanks a lot, I feel more comfortable with your explanation.

[jordisola · Accepted solution]

Hi TheHero

I completely agree, that sentence may be misleading.

Just adding one note: the term "application" in OpenShift (and in Kubernetes in general) is somehow overloaded.

When talking about resources, an "application" is just a bunch of resources with the same value for the "app" label. In other contexts, "application" refers to the set of program components deployed with a common purpose. 

But, again, I agree with you that the sentence can be improved.

KR

Jordi Sola 

[Rrm]

Hello -

Newbie here. I don't understand why this wouldn't work.

Create a new application named hello using the container located at quay.io/redhattraining/hello-world-nginx:v1.0

oc new-app --image=quay.io/redhattraining/hello-world-nginx:v1.0 --name=hello

[BennyB0Y]

Just looking at this........

""oc create deployment" creates a "DeploymentConfiguration" resource"

........ Don't you mean the "oc create deployment" creates a deployment resource, and the "oc create deploymentconfig" creates the deploymentconfig resource?
Because a deployment resource then creates a "replicasets" resource and the deploymentconfig resource then creates a "replicacontrollers" resource.

[flozano]

I'm puzzed of why oc new-app would not work with any container image that works with oc create deployment. Anyway let me give a bit of historical info about oc new-app vs oc create something.

When OpenShift 3.0 was released, Kubernetes didn't have the workloads API: deployments, jobs, statefulsets, etc didn't exist. Kubernetes only provided pods and replication controllers. OpenShift included the deploymentconfig resource to provide features such managing configuration changes and code updates (new container images) of a running applications. That work inspired the Kubernetes community and lead to the Workloads API and now Red Hat recommends using the Kubernetes Deployment resource over the OpenShift DeploymentConfig extension resource.

Running an application on Kubernetes also requires more than a workload API resource: it requires at minimum network connectivity, which means a service, and maybe configuration (secrets and config maps), storage (PVC), external connectivity (ingress or routes). Oc new-app was designed as a way of creating those other resources for typical application scenarios.

The problem is, a container image does not provide sufficient metadata for making good, automated decisions about configuration, storage, and networking needs of an application. oc new-app cannot safely do much more than creating a service and a deployment. To solve that need, OpenShift 3.0, still at the early beginnings of Kubernetes, also included templates.

Templates are just a parametrized collection of resources, that allow you to provide simple customization, for example, development vs production environments. OpenShift comes with a number of ready-to-use sample templates to deploy things such as a MySQL database with persistent storage or a PHP application that talks to a MySQL database and oc new-app is designed to use these templates.

JFYI the Kubernetes community adopted Helm charts for basically the same scenarios that you wold use OpenShift templates. The initial releases of Helm were not secure, requiring developers to have cluster administration privileges, but since Helm 3 it is considered "safe" and OpenShift 4 supports Helm. OpenShift templates are still simpler to use and manage than Helm, but Helm provides a few features absent from templates. Both templates and helm can work together with kustomize which is a more powerfull way to generate and parametrize kubernetes resources.

Another feature that you didn't have on early Kubernetes but was identified as critical to early OpenShift 3.0 users was the ability to build container images. OpenShift includes the buildconfig resource that builds container images using either the source-to-image process (S2I) or regular Dockerfiles. Those builds run inside the cluster -- you don't need a local container engine or to push you local container images to a registry server. Unlike vanilla kubernetes, OpenShift already includes a registry server, the internal registry.

oc new-app can also identify git repos containing source code designed for S2I builds or Dockerfiles, and create the buildconfig to build that image and also the deployment and service to run the resulting image, offering a quick and simple CI/CD process.

As kubernetes evolved both its workload API and its kubectl create/set commands, some use cases now overlap with oc new-app but some use cases are still unique to oc new-app. oc new-app still provides a few convenience features not provided by kubectl create deployment, for example: with oc new-app you can set environment variables, but kubectl create deployment doesn't, and it requires that you use kubectl set env on an existing deployment, and maybe you have a failed pod between kubectl create and kubectl set.

Anyway, do not expect that a deployment produced by either kubectl create deployment or oc new-app from a container image to support a "complete" and reliable application. None of them configures essential things such as health probes and resource limits. Early OpenShift 3 came with templates and sample templates to include those settings, among other reasons.

[Jcalvod]

Thank you for your comment is the great value to understand and to learn but one appointment about other perspective shared in the group is … talking about for example in ex280 exam (ocp 4.12)
When they told us you have to use this image to deploy an app … if you have to deploy it you think ok, simply based on the do280 labs in the most part of the cases this is done using of new-app but…. The good point is that internally our resources could be using the image digest SHA and if you extract image field used in the container you can see it… next if you try to use the command oc set image to change the image that this container is using to explicit value as the exercise is requesting this change not result as expected….

Really the image is the same but automatic validator detects that you have not done that exercise well … this kind of things makes difficult to get good scores based in your knowledge … and really not represent the reality….

I have another post shared today with one case explained…

[BennyB0Y]

Thanks - A good insight and a very informative contribution to this discussion. I always thought that the "deployment" resource had been around before the "deployment config" resource. #LivingAndLearning 👍