Frances Overby: Merge pull request #3422 from coligo/fmo-upd-22Feb24-c

Author: cfsdocs

Diff for: dockerfiletips.md

@@ -1,8 +1,8 @@
 ---
 
 copyright:
-  years: 2023
-lastupdated: "2023-10-09"
+  years: 2024
+lastupdated: "2024-02-22"
 
 keywords: Dockerfile for code engine, build Dockerfile in code engine, container images in code engine, tools in Dockerfile, Dockerfile, image, container as non-root
 
@@ -32,7 +32,7 @@ While you can use either strategy for your build, you might choose Dockerfile, i
 ## Dockerfile basics
 {: #dockerfile-basics}
 
-A Dockerfile describes how a container is built. Within your Dockerfile, you choose a base image that includes the necessary tools that you need during your build and runtime. You can copy files from a build context into the image, run commands, define the runtime behavior such as environment variables, exposed ports, and set the `ENTRYPOINT`. The `ENTRYPOINT` is set by the command that is invoked when the container is started. For more information about how Dockerfile instructions can be specified, see [Dockerfile reference](https://docs.docker.com/engine/reference/builder/){: external}.
+A Dockerfile describes how a container is built. Within your Dockerfile, you choose a base image that includes the necessary tools that you need during your build and runtime. You can copy files from a build context into the image, run commands, define the runtime behavior such as environment variables, exposed ports, and set the `ENTRYPOINT`. The `ENTRYPOINT` is set by the command that is invoked when the container is started. For more information about how Dockerfile instructions can be specified, see [Dockerfile reference](https://docs.docker.com/reference/dockerfile/){: external}.
 
 In a {{site.data.keyword.codeengineshort}} build, you define a source that points to a Git repository. The context that is available to the Docker build is, by default, the root directory of your Git repository. For example, if you have a directory that is named `src` in your repository, then you can use the `COPY` statement in the Dockerfile to copy this directory into your image. For example,
 
@@ -48,7 +48,7 @@ COPY . /app/src
 ```
 {: codeblock}
 
-If you copy the entire Git repository, but want to exclude some files, for example the `README.md` of the repository, then you can add a [`.dockerignore` file](https://docs.docker.com/engine/reference/builder/#dockerignore-file){: external}. Use the same file to also ignore the files and directories that you specify in your [.gitignore file](https://git-scm.com/docs/gitignore){: external}. By using the same file, you ensure that a build that you run locally has the same set of files available as the build running in {{site.data.keyword.codeengineshort}}.
+If you copy the entire Git repository, but want to exclude some files, for example the `README.md` of the repository, then you can add a [`.dockerignore` file](https://docs.docker.com/reference/dockerfile/#dockerignore-file){: external}. Use the same file to also ignore the files and directories that you specify in your [.gitignore file](https://git-scm.com/docs/gitignore){: external}. By using the same file, you ensure that a build that you run locally has the same set of files available as the build running in {{site.data.keyword.codeengineshort}}.
 {: tip}
 
 Always copy your application files into a subdirectory of the root (`/`) rather than into the root directly to avoid conflicts with operating system files. When you name your application directory, do not use one that is reserved by Unix-based operating systems, Kubernetes or {{site.data.keyword.codeengineshort}} builds, such as `/bin`, `/dev`, `/etc`, `/lib`, `/proc`, `/run`, `/sys`, `/usr`, `/var`, or `/workspace`. Naming your application directory `/app` is a best practice.

Diff for: plan-build.md

@@ -2,7 +2,7 @@
 
 copyright:
   years: 2024
-lastupdated: "2024-02-19"
+lastupdated: "2024-02-22"
 
 keywords: build for code engine, planning for code engine, source code building for code engine, source code repositories and code engine, image builds for code engine, container image builds for code engine, build strategy for code engine, build size for code engine, build, build run, source repository, image registry
 
@@ -51,7 +51,7 @@ You can choose to ignore certain file patterns from within your source code by u
 ### Dockerfile
 {: #build-dockerfile-strat}
 
-[Dockerfile](https://docs.docker.com/engine/reference/builder/){: external} build that uses the [BuildKit](https://github.com/moby/buildkit){: external} tool. To use this strategy, add a Dockerfile to your source repository. This Dockerfile describes the steps that are needed to build a container image from your source repository. The Dockerfile might contain steps that copy static files from your sources into the container to be hosted by a web service, for example. It might compile source code that is written in the language of your choice and add the resulting binary to your container image. For more information about Dockerfile builds, see [Writing a Dockerfile for {{site.data.keyword.codeengineshort}}](/docs/codeengine?topic=codeengine-dockerfile).
+[Dockerfile](https://docs.docker.com/reference/dockerfile/){: external} build that uses the [BuildKit](https://github.com/moby/buildkit){: external} tool. To use this strategy, add a Dockerfile to your source repository. This Dockerfile describes the steps that are needed to build a container image from your source repository. The Dockerfile might contain steps that copy static files from your sources into the container to be hosted by a web service, for example. It might compile source code that is written in the language of your choice and add the resulting binary to your container image. For more information about Dockerfile builds, see [Writing a Dockerfile for {{site.data.keyword.codeengineshort}}](/docs/codeengine?topic=codeengine-dockerfile).
 
 When you pull an image from Docker Hub to use with apps or jobs in Code Engine, be aware of [Docker rate limits](https://docs.docker.com/docker-hub/download-rate-limit){: external} for free plan (anonymous) users. You might experience pull limits if you receive a `429` error that indicates you reached your pull rate limit. To [increase rate limits](https://www.docker.com/increase-rate-limits){: external}, you can upgrade your account to a Docker `Pro` or `Team` subscription.
 {: tip}

Diff for: ts-build-fail-buildpushstepfails.md

@@ -1,8 +1,8 @@
 ---
 
 copyright:
-  years: 2020, 2023
-lastupdated: "2023-07-11"
+  years: 2020, 2024
+lastupdated: "2024-02-22"
 
 keywords: troubleshooting for code engine, troubleshooting builds in code engine, tips for builds in code engine, resolution of builds in code engine, builds
 
@@ -235,7 +235,7 @@ If the build and push step failure problem isn't a problem with memory, a contai
 
 If you successfully built your project locally, but the same source code does not build in {{site.data.keyword.codeengineshort}}, then you might have files available locally that are not in your Git repository. For example, for Node.js projects, it is common to run the `npm install` command locally so that project dependencies are downloaded and placed in the `node_modules` directory inside the project directory. It is a good practice to include the `node_modules` directory in the [.gitignore file](https://git-scm.com/docs/gitignore){: external} to keep your Git repository small. A common mistake is to forget to also run `npm install` (or `npm ci`) in the Dockerfile. A Docker build that you run locally can access the local `node_modules` directory, if you copy the whole project into the container, for example, by using the `COPY . /app` command in the Dockerfile. But, the {{site.data.keyword.codeengineshort}} build runs from a freshly checked-out Git repository and cannot access the `node_modules` directory. Therefore, you must run `npm install` (or `npm ci`) in the Dockerfile as part of the build.
 
-A good practice is to include directories like `node_modules` also in a [.dockerignore file](https://docs.docker.com/engine/reference/builder/#dockerignore-file){: external} so that the Docker build that you run locally behaves the same as the Code Engine build.
+A good practice is to include directories like `node_modules` also in a [.dockerignore file](https://docs.docker.com/reference/dockerfile/#dockerignore-file){: external} so that the Docker build that you run locally behaves the same as the Code Engine build.
 {: tip}
 
 Another reason for a project to be successfully built locally but to fail as {{site.data.keyword.codeengineshort}} build are security limitations. As with applications and batch jobs, {{site.data.keyword.codeengineshort}} does not allow arbitrary system operations within the {{site.data.keyword.codeengineshort}} cluster. Most of those system operations are not relevant for Docker builds anyway. However, {{site.data.keyword.codeengineshort}} does not allow opening server sockets for privileged ports. The range is `0 to 1023`. For example, if you build a web application and your build includes a test step that brings up a web application server, then you must use ports with higher numbers for this server.