mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 21:46:22 +01:00
OSDOCS-347 Bring forward Creating new applications content
This commit is contained in:
bmcelvee
@@ -537,6 +537,11 @@ Topics:
|
||||
Distros: openshift-origin
|
||||
- Name: Appendices
|
||||
File: osdk-appendices
|
||||
- Name: Application life cycle management
|
||||
Dir: application-life-cycle-management
|
||||
Topics:
|
||||
- Name: Creating applications
|
||||
File: creating-new-applications
|
||||
---
|
||||
Name: Machine management
|
||||
Dir: machine_management
|
||||
|
||||
@@ -0,0 +1,23 @@
|
||||
[id="creating-new-applications"]
|
||||
= Creating applications
|
||||
include::modules/common-attributes.adoc[]
|
||||
:context: creating-new-applications
|
||||
toc::[]
|
||||
|
||||
You can create an {product-title} application from components that include
|
||||
source or binary code, images, and templates by using the {product-title}
|
||||
CLI.
|
||||
|
||||
The set of objects created by `new-app` depends on the artifacts passed as
|
||||
input: source repositories, images, or templates.
|
||||
|
||||
[id="creating-application-using-cli-{context}"]
|
||||
== Creating an application by using the CLI
|
||||
|
||||
include::modules/applications-create-using-cli-source-code.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/applications-create-using-cli-image.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/applications-create-using-cli-template.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/applications-create-using-cli-modify.adoc[leveloffset=+2]
|
||||
46
modules/applications-create-using-cli-image.adoc
Normal file
46
modules/applications-create-using-cli-image.adoc
Normal file
@@ -0,0 +1,46 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * applications/creating-new-applications.adoc
|
||||
|
||||
[id="applications-create-using-cli-image-{context}"]
|
||||
= Creating an application from an image
|
||||
|
||||
You can deploy an application from an existing image. Images can come from
|
||||
imagestreams in the {product-title} server, images in a specific registry, or
|
||||
images in the local Docker server.
|
||||
|
||||
The `new-app` command attempts to determine the type of image specified in the
|
||||
arguments passed to it. However, you can explicitly tell `new-app` whether the
|
||||
image is a container image using the `--docker-image` argument or an imagestream
|
||||
using the `-i|--image` argument.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
If you specify an image from your local Docker repository, you must ensure that
|
||||
the same image is available to the {product-title} cluster nodes.
|
||||
====
|
||||
|
||||
== DockerHub MySQL image
|
||||
|
||||
Create an application from the DockerHub MySQL image, for example:
|
||||
|
||||
----
|
||||
$ oc new-app mysql
|
||||
----
|
||||
|
||||
== Image in a private registry
|
||||
|
||||
Create an application using an image in a private registry, specify the full
|
||||
container image specification:
|
||||
|
||||
----
|
||||
$ oc new-app myregistry:5000/example/myimage
|
||||
----
|
||||
|
||||
== Existing imagestream and optional imagestreamtag
|
||||
|
||||
Create an application from an existing imagestream and optional imagestreamtag:
|
||||
|
||||
----
|
||||
$ oc new-app my-stream:v1
|
||||
----
|
||||
213
modules/applications-create-using-cli-modify.adoc
Normal file
213
modules/applications-create-using-cli-modify.adoc
Normal file
@@ -0,0 +1,213 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * applications/creating-new-applications.adoc
|
||||
|
||||
[id="applications-create-using-cli-modify-{context}"]
|
||||
= Modifying application creation
|
||||
|
||||
The `new-app` command generates {product-title} objects that build, deploy, and
|
||||
run the application that is created. Normally, these objects are created in the
|
||||
current project and assigned names that are derived from the input source
|
||||
repositories or the input images. However, with `new-app` you can modify this
|
||||
behavior.
|
||||
|
||||
.`new-app` output objects
|
||||
[cols="2,8",options="header"]
|
||||
|===
|
||||
|
||||
|Object |Description
|
||||
|
||||
|`BuildConfig`
|
||||
|A `BuildConfig` is created for each source repository that is specified in the
|
||||
command line. The `BuildConfig` specifies the strategy to use, the source
|
||||
location, and the build output location.
|
||||
|
||||
|`ImageStreams`
|
||||
|For `BuildConfig`, two `ImageStreams` are usually created. One
|
||||
represents the input image. With `Source` builds, this is the builder image.
|
||||
ifndef::openshift-online[]
|
||||
With `Docker` builds, this is the *FROM* image.
|
||||
endif::[]
|
||||
The second one represents the output image. If a container image was specified
|
||||
as input to `new-app`, then an imagestream is created for that image as well.
|
||||
|
||||
|`DeploymentConfig`
|
||||
|A `DeploymentConfig` is created either to deploy the output of a build, or a
|
||||
specified image. The `new-app` command creates `emptyDir` volumes for all Docker
|
||||
volumes that are specified in containers included in the resulting
|
||||
`DeploymentConfig`.
|
||||
|
||||
|`Service`
|
||||
|The `new-app` command attempts to detect exposed ports in input images. It
|
||||
uses the lowest numeric exposed port to generate a service that exposes that
|
||||
port. In order to expose a different port, after `new-app` has completed, simply
|
||||
use the `oc expose` command to generate additional services.
|
||||
|
||||
|Other
|
||||
|Other objects can be generated when instantiating templates, according to the
|
||||
template.
|
||||
|
||||
|===
|
||||
|
||||
== Specifying environment variables
|
||||
|
||||
When generating applications from a template, source, or an image, you can use
|
||||
the `-e|--env` argument to pass environment variables to the application
|
||||
container at run time:
|
||||
|
||||
----
|
||||
$ oc new-app openshift/postgresql-92-centos7 \
|
||||
-e POSTGRESQL_USER=user \
|
||||
-e POSTGRESQL_DATABASE=db \
|
||||
-e POSTGRESQL_PASSWORD=password
|
||||
----
|
||||
|
||||
The variables can also be read from file using the `--env-file` argument:
|
||||
|
||||
----
|
||||
$ cat postgresql.env
|
||||
POSTGRESQL_USER=user
|
||||
POSTGRESQL_DATABASE=db
|
||||
POSTGRESQL_PASSWORD=password
|
||||
$ oc new-app openshift/postgresql-92-centos7 --env-file=postgresql.env
|
||||
----
|
||||
|
||||
Additionally, environment variables can be given on standard input by using
|
||||
`--env-file=-`:
|
||||
|
||||
----
|
||||
$ cat postgresql.env | oc new-app openshift/postgresql-92-centos7 --env-file=-
|
||||
----
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
Any `BuildConfig` objects created as part of `new-app` processing are not
|
||||
updated with environment variables passed with the `-e|--env` or `--env-file` argument.
|
||||
====
|
||||
|
||||
== Specifying build environment variables
|
||||
|
||||
When generating applications from a template, source, or an image, you can use
|
||||
the `--build-env` argument to pass environment variables to the build container
|
||||
at run time:
|
||||
|
||||
----
|
||||
$ oc new-app openshift/ruby-23-centos7 \
|
||||
--build-env HTTP_PROXY=http://myproxy.net:1337/ \
|
||||
--build-env GEM_HOME=~/.gem
|
||||
----
|
||||
|
||||
The variables can also be read from a file using the `--build-env-file` argument:
|
||||
|
||||
----
|
||||
$ cat ruby.env
|
||||
HTTP_PROXY=http://myproxy.net:1337/
|
||||
GEM_HOME=~/.gem
|
||||
$ oc new-app openshift/ruby-23-centos7 --build-env-file=ruby.env
|
||||
----
|
||||
|
||||
Additionally, environment variables can be given on standard input by using
|
||||
`--build-env-file=-`:
|
||||
|
||||
----
|
||||
$ cat ruby.env | oc new-app openshift/ruby-23-centos7 --build-env-file=-
|
||||
----
|
||||
|
||||
== Specifying labels
|
||||
|
||||
When generating applications from source, images, or templates, you
|
||||
can use the `-l|--label` argument to add labels to the created objects. Labels
|
||||
make it easy to collectively select, configure, and delete objects associated
|
||||
with the application.
|
||||
|
||||
----
|
||||
$ oc new-app https://github.com/openshift/ruby-hello-world -l name=hello-world
|
||||
----
|
||||
|
||||
== Viewing the output without creation
|
||||
|
||||
To see a dry-run of running the `new-app` command, you can use the `-o|--output`
|
||||
argument with a `yaml` or `json` value. You can then use the output to preview
|
||||
the objects that are created or redirect it to a file that you can edit.
|
||||
After you are satisfied, you can use `oc create` to create the {product-title}
|
||||
objects.
|
||||
|
||||
To output `new-app` artifacts to a file, edit them, then create them:
|
||||
|
||||
----
|
||||
$ oc new-app https://github.com/openshift/ruby-hello-world \
|
||||
-o yaml > myapp.yaml
|
||||
$ vi myapp.yaml
|
||||
$ oc create -f myapp.yaml
|
||||
----
|
||||
|
||||
== Creating objects with different names
|
||||
|
||||
Objects created by `new-app` are normally named after the source repository, or
|
||||
the image used to generate them. You can set the name of the objects produced by
|
||||
adding a `--name` flag to the command:
|
||||
|
||||
----
|
||||
$ oc new-app https://github.com/openshift/ruby-hello-world --name=myapp
|
||||
----
|
||||
|
||||
== Creating objects in a different project
|
||||
|
||||
Normally, `new-app` creates objects in the current project. However, you can
|
||||
create objects in a different project by using the `-n|--namespace` argument:
|
||||
|
||||
----
|
||||
$ oc new-app https://github.com/openshift/ruby-hello-world -n myproject
|
||||
----
|
||||
|
||||
== Creating multiple objects
|
||||
|
||||
The `new-app` command allows creating multiple applications specifying multiple
|
||||
parameters to `new-app`. Labels specified in the command line apply to all
|
||||
objects created by the single command. Environment variables apply to all
|
||||
components created from source or images.
|
||||
|
||||
To create an application from a source repository and a Docker Hub image:
|
||||
|
||||
----
|
||||
$ oc new-app https://github.com/openshift/ruby-hello-world mysql
|
||||
----
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
If a source code repository and a builder image are specified as separate
|
||||
arguments, `new-app` uses the builder image as the builder for the source code
|
||||
repository. If this is not the intent, specify the required builder image for
|
||||
the source using the `~` separator.
|
||||
====
|
||||
|
||||
== Grouping images and source in a single Pod
|
||||
|
||||
The `new-app` command allows deploying multiple images together in a single Pod.
|
||||
In order to specify which images to group together, use the `+` separator. The
|
||||
`--group` command line argument can also be used to specify the images that should
|
||||
be grouped together. To group the image built from a source repository with
|
||||
other images, specify its builder image in the group:
|
||||
|
||||
----
|
||||
$ oc new-app ruby+mysql
|
||||
----
|
||||
|
||||
To deploy an image built from source and an external image together:
|
||||
|
||||
----
|
||||
$ oc new-app \
|
||||
ruby~https://github.com/openshift/ruby-hello-world \
|
||||
mysql \
|
||||
--group=ruby+mysql
|
||||
----
|
||||
|
||||
== Searching for images, templates, and other inputs
|
||||
|
||||
To search for images, templates, and other inputs for the `oc new-app` command,
|
||||
add the `--search` and `--list` flags. For example, to find all of the images or
|
||||
templates that include PHP:
|
||||
|
||||
----
|
||||
$ oc new-app --search php
|
||||
----
|
||||
173
modules/applications-create-using-cli-source-code.adoc
Normal file
173
modules/applications-create-using-cli-source-code.adoc
Normal file
@@ -0,0 +1,173 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * applications/creating-new-applications.adoc
|
||||
|
||||
[id="applications-create-using-cli-source-code-{context}"]
|
||||
= Creating an application from source code
|
||||
|
||||
With the `new-app` command you can create applications from source code in a
|
||||
local or remote Git repository.
|
||||
|
||||
The `new-app` command creates a build configuration, which itself creates a new
|
||||
application image from your source code. The `new-app` command typically also
|
||||
creates a deployment configuration to deploy the new image, and a service to
|
||||
provide load-balanced access to the deployment running your image.
|
||||
|
||||
{product-title} automatically detects whether the `Pipeline` or `Source`
|
||||
build strategy should be used, and in the case of `Source` builds,
|
||||
detects an appropriate language builder image.
|
||||
|
||||
== Local
|
||||
|
||||
To create an application from a Git repository in a local directory:
|
||||
|
||||
----
|
||||
$ oc new-app /<path to source code>
|
||||
----
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
If you use a local Git repository, the repository must have a remote named
|
||||
`origin` that points to a URL that is accessible by the {product-title} cluster. If
|
||||
there is no recognized remote, running the `new-app` command will create a binary build.
|
||||
====
|
||||
|
||||
== Remote
|
||||
|
||||
To create an application from a remote Git repository:
|
||||
|
||||
----
|
||||
$ oc new-app https://github.com/sclorg/cakephp-ex
|
||||
----
|
||||
|
||||
To create an application from a private remote Git repository:
|
||||
|
||||
----
|
||||
$ oc new-app https://github.com/youruser/yourprivaterepo --source-secret=yoursecret
|
||||
----
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
If you use a private remote Git repository, you can use the `--source-secret` flag
|
||||
to specify an existing source clone secret that will get injected into your
|
||||
`BuildConfig` to access the repository.
|
||||
====
|
||||
|
||||
You can use a subdirectory of your source code repository by specifying a
|
||||
`--context-dir` flag. To create an application from a remote Git repository and
|
||||
a context subdirectory:
|
||||
|
||||
----
|
||||
$ oc new-app https://github.com/sclorg/s2i-ruby-container.git \
|
||||
--context-dir=2.0/test/puma-test-app
|
||||
----
|
||||
|
||||
Also, when specifying a remote URL, you can specify a Git branch to use by
|
||||
appending `#<branch_name>` to the end of the URL:
|
||||
|
||||
----
|
||||
$ oc new-app https://github.com/openshift/ruby-hello-world.git#beta4
|
||||
----
|
||||
|
||||
== Build strategy detection
|
||||
|
||||
If a `Jenkinsfile` exists in the root or specified context directory of the
|
||||
source repository when creating a new application, {product-title} generates a
|
||||
Pipeline build strategy.
|
||||
|
||||
Otherwise, it generates a Source build strategy.
|
||||
|
||||
Override the build strategy by setting the `--strategy` flag to either
|
||||
`pipeline` or `source`.
|
||||
|
||||
----
|
||||
$ oc new-app /home/user/code/myapp --strategy=docker
|
||||
----
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
The `oc` command requires that files containing build sources are available in a
|
||||
remote Git repository. For all source builds, you must use `git remote -v`.
|
||||
====
|
||||
|
||||
== Language Detection
|
||||
|
||||
If you use the `Source` build strategy, `new-app` attempts to determine the
|
||||
language builder to use by the presence of certain files in the root or
|
||||
specified context directory of the repository:
|
||||
|
||||
.Languages Detected by `new-app`
|
||||
[cols="4,8",options="header"]
|
||||
|===
|
||||
|
||||
|Language |Files
|
||||
ifdef::openshift-enterprise,openshift-dedicated,openshift-aro,openshift-online[]
|
||||
|`dotnet`
|
||||
|`project.json`, `pass:[*.csproj]`
|
||||
endif::[]
|
||||
|`jee`
|
||||
|`pom.xml`
|
||||
|
||||
|`nodejs`
|
||||
|`app.json`, `package.json`
|
||||
|
||||
|`perl`
|
||||
|`cpanfile`, `index.pl`
|
||||
|
||||
|`php`
|
||||
|`composer.json`, `index.php`
|
||||
|
||||
|`python`
|
||||
|`requirements.txt`, `setup.py`
|
||||
|
||||
|`ruby`
|
||||
|`Gemfile`, `Rakefile`, `config.ru`
|
||||
|
||||
|`scala`
|
||||
|`build.sbt`
|
||||
|
||||
|`golang`
|
||||
|`Godeps`, `main.go`
|
||||
|===
|
||||
|
||||
After a language is detected, `new-app` searches the {product-title} server for
|
||||
imagestreamtags that have a `supports` annotation matching the detected language,
|
||||
or an imagestream that matches the name of the detected language. If a match is
|
||||
not found, `new-app` searches the link:https://registry.hub.docker.com[Docker Hub
|
||||
registry] for an image that matches the detected language based on name.
|
||||
|
||||
You can override the image the builder uses for a particular source
|
||||
repository by specifying the image, either an imagestream or container
|
||||
specification, and the repository with a `~` as a separator. Note that if this
|
||||
is done, build strategy detection and language detection are not carried out.
|
||||
|
||||
For example, to use the `myproject/my-ruby` imagestream with the source in a
|
||||
remote repository:
|
||||
|
||||
----
|
||||
$ oc new-app myproject/my-ruby~https://github.com/openshift/ruby-hello-world.git
|
||||
----
|
||||
|
||||
To use the `openshift/ruby-20-centos7:latest `container imagestream with
|
||||
the source in a local repository:
|
||||
|
||||
----
|
||||
$ oc new-app openshift/ruby-20-centos7:latest~/home/user/code/my-ruby-app
|
||||
----
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
Language detection requires the Git client to be locally installed so that your
|
||||
repository can be cloned and inspected. If Git is not available, you can avoid
|
||||
the language detection step by specifying the builder image to use with your
|
||||
repository with the `<image>~<repository>` syntax.
|
||||
|
||||
The `-i <image> <repository>` invocation requires that `new-app` attempt
|
||||
to clone `repository` in order to determine what type of artifact it is, so this
|
||||
will fail if Git is not available.
|
||||
|
||||
The `-i <image> --code <repository>` invocation requires
|
||||
`new-app` clone `repository` in order to determine whether `image` should be
|
||||
used as a builder for the source code, or deployed separately, as in the case of
|
||||
a database image.
|
||||
====
|
||||
47
modules/applications-create-using-cli-template.adoc
Normal file
47
modules/applications-create-using-cli-template.adoc
Normal file
@@ -0,0 +1,47 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * applications/creating-new-applications.adoc
|
||||
|
||||
[id="applications-create-using-cli-template-{context}"]
|
||||
= Creating an application from a template
|
||||
|
||||
You can create an application from a previously stored template or from a
|
||||
template file, by specifying the name of the template as an argument. For
|
||||
example, you can store a sample application template and use it to create an
|
||||
application.
|
||||
|
||||
Create an application from a stored template, for example:
|
||||
|
||||
----
|
||||
$ oc create -f examples/sample-app/application-template-stibuild.json
|
||||
$ oc new-app ruby-helloworld-sample
|
||||
----
|
||||
|
||||
To directly use a template in your local file system, without first storing it
|
||||
in {product-title}, use the `-f|--file` argument. For example:
|
||||
|
||||
----
|
||||
$ oc new-app -f examples/sample-app/application-template-stibuild.json
|
||||
----
|
||||
|
||||
== Template Parameters
|
||||
|
||||
When creating an application based on a template, use the
|
||||
`-p|--param` argument to set parameter values that are defined by the template:
|
||||
|
||||
----
|
||||
$ oc new-app ruby-helloworld-sample \
|
||||
-p ADMIN_USERNAME=admin -p ADMIN_PASSWORD=mypassword
|
||||
----
|
||||
|
||||
You can store your parameters in a file, then use that file with
|
||||
`--param-file` when instantiating a template. If you want to read the
|
||||
parameters from standard input, use `--param-file=-`:
|
||||
|
||||
----
|
||||
$ cat helloworld.params
|
||||
ADMIN_USERNAME=admin
|
||||
ADMIN_PASSWORD=mypassword
|
||||
$ oc new-app ruby-helloworld-sample --param-file=helloworld.params
|
||||
$ cat helloworld.params | oc new-app ruby-helloworld-sample --param-file=-
|
||||
----
|
||||
Reference in New Issue
Block a user