You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: appdeploy-plan.md
+16-1Lines changed: 16 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
3
3
copyright:
4
4
years: 2020, 2022
5
-
lastupdated: "2022-01-12"
5
+
lastupdated: "2022-01-19"
6
6
7
7
keywords: applications in code engine, apps in code engine, http requests in code engine, deploy apps in code engine, app workloads in code engine, deploying workloads in code engine, application, app, memory, cpu, environment variables
8
8
@@ -36,6 +36,21 @@ When you deploy your application, the most current version of your referenced co
36
36
By default, {{site.data.keyword.codeengineshort}} assumes that apps listen for incoming connections on port `8080`. In addition, Code Engine sets the PORT environment variable to the port value that the application is expected to be listening on. If your app needs to listen on a port other than port `8080`, either deploy your app from the console and specify the correct port or use the `--port` option on the `app create` command. For more information about environment variables that are set by {{site.data.keyword.codeengineshort}}, see [Automatically injected environment variables](/docs/codeengine?topic=codeengine-inside-env-vars).
37
37
{: important}
38
38
39
+
## Considerations for HTTP handling
40
+
{: #considerationshttphandlingapp}
41
+
42
+
When you are working with applications (or jobs), it is helpful to be aware of basic HTTP handling in {{site.data.keyword.codeengineshort}}.
43
+
44
+
- For incoming application connections that use HTTP, the transport layer security (TLS) aspects are managed automatically by {{site.data.keyword.codeengineshort}} outside of the application code. The HTTP server for the application needs to be concerned about only HTTP connectivity and not HTTPS connectivity.
45
+
46
+
- Internet connections that are bound for {{site.data.keyword.codeengineshort}} applications are automatically redirected to use HTTPS.
47
+
48
+
- Outbound connections from applications to other {{site.data.keyword.codeengineshort}} applications are automatically protected by TLS. {{site.data.keyword.codeengineshort}} automatically manages this connectivity, so the protocol (or URL) that is used is `HTTP` and not `HTTPS`.
49
+
50
+
- Outbound connections from applications to non-{{site.data.keyword.codeengineshort}} applications, such as the internet, use `HTTP` or `HTTPS` depending on the protocol that is specified in the app code or URL.
51
+
52
+
- Outbound connections from batch jobs use the `HTTP` or `HTTPS` protocol that is specified in the job code or URL. This behavior includes connections from batch jobs to {{site.data.keyword.codeengineshort}} apps.
53
+
39
54
## Options for visibility for a {{site.data.keyword.codeengineshort}} application
Copy file name to clipboardExpand all lines: build.md
+111-5Lines changed: 111 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
3
3
copyright:
4
4
years: 2022
5
-
lastupdated: "2022-01-12"
5
+
lastupdated: "2022-01-20"
6
6
7
7
keywords: builds for code engine, builds, building, source code, build run, application image builds for code engine, job image builds for code engine, container image builds with code engine
8
8
@@ -18,14 +18,14 @@ subcollection: codeengine
18
18
A build, or image build, is a mechanism that you can use to create a container image from your source code. {{site.data.keyword.codeengineshort}} supports building from a Dockerfile and Cloud Native Buildpacks.
19
19
{: shortdesc}
20
20
21
-
{{site.data.keyword.codeenginefull}} pulls source code from a repository, builds it, and then pushes the container image to a registry. You can choose public or private [repositories](/docs/codeengine?topic=codeengine-code-repositories) and [registries](/docs/codeengine?topic=codeengine-add-registry). With {{site.data.keyword.codeengineshort}}, you first set up the option for your build configuration and then you run it. After your build is complete, you can deploy the container images as applications or run them as jobs. Before you start building images, review [planning information](/docs/codeengine?topic=codeengine-plan-build).
21
+
{{site.data.keyword.codeenginefull}} pulls source code from a repository or a local directory, builds it, and then pushes the container image to a registry. You can choose public or private [repositories](/docs/codeengine?topic=codeengine-code-repositories) and [registries](/docs/codeengine?topic=codeengine-add-registry). With {{site.data.keyword.codeengineshort}}, you first set up the option for your build configuration and then you run it. After your build is complete, you can deploy the container images as applications or run them as jobs. Before you start building images, review [planning information](/docs/codeengine?topic=codeengine-plan-build).
22
22
23
23
Note that if you build multiple versions of the same container image, the most current version of the container image is downloaded and used when you run your job or deploy your application.
24
24
25
25
## Create a build configuration that pulls source from public repository
26
26
{: #build-create-config}
27
27
28
-
You can create a build configuration that pulls source from a public repository. You must specify the details of your source repository, the build [strategy](/docs/codeengine?topic=codeengine-plan-build#build-strategy), and the [build size](/docs/codeengine?topic=codeengine-plan-build#build-size) that you decided to use, and the container image details to store the container image.
28
+
You can create a build configuration that pulls source from a public repository. You must specify the details of your source, the build [strategy](/docs/codeengine?topic=codeengine-plan-build#build-strategy), and the [build size](/docs/codeengine?topic=codeengine-plan-build#build-size) that you decided to use, and the container image details to store the container image.
29
29
30
30
Creating a build configuration does not create an image, but creates the configuration to build an image. You must then run a build that references the build configuration to create an image. The build configuration is not validated or used to create an image until the build is run. The build configuration enables multiple subsequent builds of an image, such as when changes are applied to the source repository.
31
31
{: tip}
@@ -156,7 +156,7 @@ Creating a build configuration does not create an image, but creates the configu
156
156
5. In the **Source** section, enter a name for your build, the URL of your source repository, and your code repo access. If your code is in a private repo, use an SSH URL for the code repository URL and either select the name of an existing code repo access or [create a code repo access](/docs/codeengine?topic=codeengine-code-repositories). An example of an SSH URL is `[email protected]:IBM/CodeEngine.git`. Optionally, select a source branch name. If you do not provide a branch name and you leave the field empty, {{site.data.keyword.codeengineshort}} automatically uses the default branch of the specified repository. You can enter any other branch name, tag, or commit ID. Click **Next** to continue.
157
157
6. In the **Strategy** section, select the [strategy](/docs/codeengine?topic=codeengine-plan-build#build-strategy) that you want to use. If you select **Dockerfile**, you can also specify an alternative path for your Dockerfile. Select the size of your build under **Build resources**. Click **Next** to advance to the last section.
158
158
7. In the **Output** section, you enter the details of your container image. Select your registry, or click **Add registry** to add a new one. Then, select the namespace, repository, and tag of the image you want to build. For {{site.data.keyword.registryshort}}, you can select from the existing images, or enter a new repository or tag.
159
-
8. Click **Done** to finish the creation of the build.
159
+
8. Click **Done** to finish the creation of the build.
160
160
161
161
### Creating a build configuration with the CLI (private)
## Create a build configuration that pulls source from a local directory
190
+
{: #build-config-local}
191
+
192
+
You can create a build configuration that pulls source from a local directory by using only the {{site.data.keyword.codeengineshort}} CLI. You must specify the details of your source repository, the build [strategy](/docs/codeengine?topic=codeengine-plan-build#build-strategy), and the [build size](/docs/codeengine?topic=codeengine-plan-build#build-size) that you decided to use, and the container image details to store the container image.
193
+
194
+
When you submit a build that pulls code from a local directory, your source code is packed into an archive file and uploaded to your {{site.data.keyword.registrylong_notm}} instance. You can choose to ignore certain file patterns from within your source code by using the `.ceignore` file, which behaves similarly to a `.gitignore` file. The source image is created in the same namespace as your build image.
195
+
196
+
Creating a build configuration does not create an image, but creates the configuration to build an image. You must then run a build that references the build configuration to create an image. The build configuration is not validated or used to create an image until the build is run. The build configuration enables multiple subsequent builds of an image, such as when changes are applied to the source repository.
197
+
{: tip}
198
+
199
+
### Creating a build configuration with the CLI (local)
200
+
{: #build-config-local-cli}
201
+
202
+
To create a build configuration that pulls code from a local directory with the CLI, use the **`build create`** command and specify the `build-type` as `local`. This command requires a name, an image, and a registry secret and also allows other optional arguments. For a complete listing of options, see the [**`ibmcloud ce build create`**](/docs/codeengine?topic=codeengine-cli#cli-build-create) command.
203
+
{: shortdesc}
204
+
205
+
Before you begin
206
+
207
+
-[Set up your {{site.data.keyword.codeengineshort}} CLI environment](/docs/codeengine?topic=codeengine-install-cli).
208
+
-[Create and work with a project](/docs/codeengine?topic=codeengine-manage-project).
209
+
-[Create a registry secret so you can save your image](/docs/codeengine?topic=codeengine-add-registry).
210
+
211
+
The following example command creates a build configuration that pulls source from a local directory, puts the image in the `mynamespace` namespace that is defined in `us.icr.io`, and uses the `myregistry` registry access secret that is known to {{site.data.keyword.codeengineshort}}.
212
+
213
+
```sh
214
+
ibmcloud ce build create -name build-local-dockerfile -build-type local -image us.icr.io/mynamespace/codeengine-build --registry-secret myregistry -dockerfile Dockerfile -strategy dockerfile -size medium
215
+
```
216
+
{: pre}
217
+
189
218
## Running a build
190
219
{: #build-run}
191
220
@@ -209,7 +238,7 @@ After you create a build configuration, you can submit a run based on that build
209
238
210
239
Monitor your build progress in the **Build runs** section.
211
240
212
-
### Creating a build run with the CLI
241
+
### Creating a build run with the CLI for source from a repository (non-local)
213
242
{: #build-run-cli}
214
243
215
244
To submit a build run from a build configuration with the CLI, use the **`buildrun submit`** command. This command requires the name of a build configuration and also allows other optional arguments. For a complete listing of options, see the [**`ibmcloud ce buildrun submit`**](/docs/codeengine?topic=codeengine-cli#cli-buildrun-submit) command.
@@ -271,6 +300,83 @@ Reason: Succeeded
271
300
272
301
For more information about builds, check the [troubleshooting tips](/docs/codeengine?topic=codeengine-troubleshoot-build).
273
302
303
+
304
+
### Creating a build run with the CLI for source from a local directory (local)
305
+
{: #build-run-cli-local}
306
+
307
+
To submit a build run from a build configuration with the CLI that pulls source from a local directory, use the **`buildrun submit`** command. This command requires the name of a build configuration, the path to your local source, and it also allows other optional arguments. For a complete listing of options, see the [**`ibmcloud ce buildrun submit`**](/docs/codeengine?topic=codeengine-cli#cli-buildrun-submit) command.
308
+
{: shortdesc}
309
+
310
+
The following scenario clones the [Samples for {{site.data.keyword.codeenginefull_notm}} GitHub repo](https://github.com/IBM/CodeEngine){: external} into a `CodeEngineLocalSample` directory on your local machine.
311
+
312
+
1. Clone the [Samples for {{site.data.keyword.codeenginefull_notm}} GitHub repo](https://github.com/IBM/CodeEngine){: external} to a subdirectory that is created on your local machine, such as the `CodeEngineLocalSamples` subdirectory. From this directory, run the `git clone` command; for example,
313
+
314
+
```sh
315
+
git clone https://github.com/IBM/CodeEngine
316
+
```
317
+
{: pre}
318
+
319
+
2. Go to the directory where your source code is located on your machine. For example, go to the `CodeEngine` subdirectory as this is the directory where the {{site.data.keyword.codeengineshort}} Samples reside.
320
+
321
+
3. From the directory where your source code resides, submit the build run. The following example runs a build that is called `buildrun-local-dockerfile`and uses the `build-local-dockerfile` build configuration. The `--source` option specifies the path to the source on the local machine to the `helloworld` sample.
The following example shows the output of the **`buildrun submit`** command.
329
+
330
+
```sh
331
+
Getting build 'build-local-dockerfile'
332
+
Packaging files to upload from source path './helloworld' ...
333
+
Submitting build run 'buildrun-local-dockerfile'...
334
+
Run 'ibmcloud ce buildrun get -n buildrun-local-dockerfile' to check the build run status.
335
+
OK
336
+
```
337
+
{: screen}
338
+
339
+
4. Monitor the progress of your build run by using the [**`ibmcloud ce buildrun get`**](/docs/codeengine?topic=codeengine-cli#cli-build-get) command. For example, to check the status of the build run from the previous example,
340
+
341
+
```sh
342
+
ibmcloud ce buildrun get --name helloworld-build-run
343
+
```
344
+
{: pre}
345
+
346
+
The following example shows the output of the **`build get`** command.
347
+
348
+
```sh
349
+
Getting build run 'buildrun-local-dockerfile'...
350
+
Run 'C:\Program Files\IBM\Cloud\bin\ibmcloud.exe ce buildrun events -n buildrun-local-dockerfile' to get the system events of the build run.
351
+
Run 'C:\Program Files\IBM\Cloud\bin\ibmcloud.exe ce buildrun logs -f -n buildrun-local-dockerfile' to follow the logs of the build run.
When you submit a build that pulls code from a local directory, your source code is packed into an archive file and uploaded to your {{site.data.keyword.registrylong_notm}} instance. After the build run is completed, you can see your built image, such as `codeengine-build`, in the {{site.data.keyword.registrylong_notm}} instance. You also see a source image with `-source` appended to the name of your build, such as `codeengine-build-source`. You can delete this source image without impact.
376
+
{: note}
377
+
378
+
For more information about builds, check the [troubleshooting tips](/docs/codeengine?topic=codeengine-troubleshoot-build).
0 commit comments