TheHero
Mission Specialist
Mission Specialist
  • 4,124 Views

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

Jump to solution

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.

Labels (3)
0 Kudos
1 Solution

Accepted Solutions
jordisola
Flight Engineer
Flight Engineer
  • 4,058 Views

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 

View solution in original post

6 Replies
jordisola
Flight Engineer
Flight Engineer
  • 4,109 Views

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

Tags (1)
TheHero
Mission Specialist
Mission Specialist
  • 4,087 Views

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.

 

 

0 Kudos
jordisola
Flight Engineer
Flight Engineer
  • 4,059 Views

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 

BennyB0Y
Cadet
Cadet
  • 2,124 Views

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
Moderator
Moderator
  • 1,888 Views

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.

BennyB0Y
Cadet
Cadet
  • 1,762 Views
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 👍
Join the discussion
You must log in to join this conversation.