Tweaking production/development language to distroless/dev

content/chainguard/chainguard-images/about/_index.md

@@ -38,9 +38,9 @@ tutorials: [
     url: "/chainguard/chainguard-images/working-with-images/about/images-compiled-programs/compiled-programs"
   },
   {
-    title: "Dev vs. Production Images",
+    title: "Understanding Starter Images",
     description: "",
-    url: "/chainguard/chainguard-images/about/differences-development-production/"
+    url: "/chainguard/chainguard-images/about/understanding-starter-images/"
   },
     {
     title: "Product Release Lifecycle",

content/chainguard/chainguard-images/about/getting-started-distroless.md

@@ -27,7 +27,7 @@ This minimal approach offers several benefits, including:
 - **Simplified Dependency Management:** Traditional container images can introduce dependency bloat, making it difficult to track and manage exactly what's included. Distroless images keep things clear by only containing what's directly required for the application to function.
 - **Potentially Smaller Image Sizes:** By eliminating extraneous OS components, distroless images can be significantly smaller than their full-blown counterparts.
 
-Chainguard offers a mix of distroless and development (or builder) images that are minimalist and contain provenance attestations for increased security. Since distroless images have fewer tools and don't come with a package manager, some adaptation might be necessary when migrating from traditional base images. A typical approach is using multi stage builds to compose a final distroless image containing the additional artifacts required by the application in order to run successfully.
+Chainguard offers a mix of distroless and `-dev` (or Starter) images that are minimalist and contain provenance attestations for increased security. Since distroless images have fewer tools and don't come with a package manager, some adaptation might be necessary when migrating from traditional base images. A typical approach is using multi stage builds to compose a final distroless image containing the additional artifacts required by the application in order to run successfully.
 
 ## Multi Stage Builds
 A multi stage build is a technique for creating slimmer and more efficient container images. It allows you to define multiple stages within a single Dockerfile. Each stage acts like a separate build environment with its own base image and instructions.

content/chainguard/chainguard-images/about/understanding-starter-images.md

@@ -0,0 +1,65 @@
+---
+title: "Understanding Chainguard's Starter Images"
+linktitle: "Starter Images"
+aliases:
+- /chainguard/chainguard-images/differences-development-production/
+- /chainguard/chainguard-images/about/differences-development-production/
+type: "article"
+description: "Learn about Chainguard's Starter images and what makes them different from our regular minimal container images."
+date: 2024-11-01T07:52:00+02:00
+lastmod: 2025-01-17T07:52:00+02:00
+draft: false
+tags: ["CHAINGUARD IMAGES", "PRODUCT", "CONCEPTUAL"]
+images: []
+menu:
+  docs:
+    parent: "about"
+weight: 020
+toc: true
+---
+
+Chainguard Container Images follow a distroless philosophy, meaning that only software absolutely necessary for a specific workload is included in an image. Chainguard's minimal images provide a runtime for production workloads and are designed to have as few packages as possible. This means they typically do not contain package managers such as apk, shells such as bash, or development utilities such as Git or text editors.
+
+However, there are times when an organization would prefer to run container images that do include a shell or package manager, but otherwise only contain the minimum dependencies needed to function. For cases like this, Chainguard offers its **Starter images**. 
+
+Starter images (sometimes referred to as `-dev` images) are designed for development tasks such as building, testing, or debugging. They can be used to build software artifacts that are then copied into minimal images as part of a multi-stage build, or to test workflows interactively in an environment similar to a minimal image. Starter images contain familiar utilities such as package managers and shells, and are tagged with `:latest-dev`. 
+
+While we encourage you to use minimal images in your live deployments, `-dev` images are useful for many parts of the development lifecycle, and are even secure and production-ready. This article explains some of the key differences between Starter images and Chainguard's standard minimal variants, and outlines ways they come together in creating a secure deployment.
+
+## Minimal Images Security
+
+Chainguard's standard minimal images (as in, non-Starter images) have the following advantages:
+
+- Minimal images contain fewer packages. While Chainguard moves quickly to patch CVEs in all images, our minimal images still experience fewer CVEs overall. Reducing the number of packages also reduces the potential number of unknown vulnerabilities that might apply to an image.
+- Not all executables are created equal. Shells such as bash, package managers such as apk, and communication-ready utilities such as Git and cURL are general-purpose tools that are broadly exploitable.
+- A smaller image can use fewer resources and reduce deployment time. In some cases, especially with images that are already large, a smaller version can make a deployment more stable or robust.
+- Removing unnecessary components increases the observability and transparency of the image. Reducing the number of components can also facilitate risk assessment or post-incident reporting.
+
+
+## Using Starter Images
+
+Like our minimal container images, Chainguard's Starter images also feature few-to-zero CVEs, include useful attestations such as SLSA provenance and SBOMs, and follow other security best practices. You should feel comfortable using these secure images in production if they better fit your use case.
+
+Though we encourage the use of minimal images in your final deployment, Starter images have many use cases. These include:
+
+- **Building**: In many Dockerfile builds, you will need to generate software artifacts such as static binaries or virtual environments as part of the build process. Starter images are ideal for this use case, and after generation artifacts can be copied to a minimal image for use. Check out [How to Port a Sample Application to Chainguard Images](/chainguard/migration/porting-apps-to-chainguard/) for a detailed example.
+- **Debugging**: Chaingaurd's Starter container images contain a number of useful utilities, but are otherwise designed to be as close as possible to the minimal variant. This makes them useful for debugging, since you can test out build steps or the build environment using interactive shells and package managers. Refer to our article on [Debugging Distroless Images](/chainguard/chainguard-images/troubleshooting/debugging-distroless-images/#1-using-dev--debug-image-variants) for more on this use case.
+- **Training**: In the case of AI images, you can use a `-dev` variant to train a model, then run the model in inference using a minimal image.
+- **Deploying**: Though we encourage you to use our minimal images in your live deployment where possible, our Starter images similarly have few-to-zero CVEs and are suitable for production.
+
+## Special Considerations
+
+It’s likely already clear that switching to Chainguard's minimal images requires a few changes in development and deployment. Here are a few additional considerations:
+
+* Since we don’t include general-purpose shells in our minimal images, the entrypoint to these images will vary by each image’s use case. Check the documentation for each image, and note that Dockerfile commands such as `CMD` will be directed to the image-specific entrypoint. Because we aim to keep our Starter images as close as possible to our minimal images, these changes to the entrypoint also affect the Starter variants.
+* Chainguard Images use a less privileged user by default. When using our Starter images, you will need to explicitly access the image with the root user — such as by including the `--user root` option — to perform tasks such as installing packages with apk.
+
+## Conclusion
+
+If you're just starting out, using Chainguard's minimal images can be an adjustment. Our Starter images provide options and flexibility as you secure your production infrastructure. Starter images are also secure and ready for use in production.
+
+### Resources
+
+* [Blog: Minimal container images: Towards a more secure future](https://www.chainguard.dev/unchained/minimal-container-images-towards-a-more-secure-future)
+* [Chainguard Academy: Overview of Chainguard Images](/chainguard/chainguard-images/overview#why-distroless)
+* [Chainguard Academy: Debugging Distroless Images](/chainguard/chainguard-images/debugging-distroless-images/)

content/chainguard/chainguard-images/getting-started/php.md

@@ -17,7 +17,7 @@ weight: 045
 toc: true
 ---
 
-The PHP images maintained by Chainguard include both development and production container images, suitable for building and running PHP workloads. The `latest-fpm` variant serves PHP applications over FastCGI, while the `latest` variant runs PHP applications from the command line.
+The PHP images maintained by Chainguard include both [minimal images and our Starter container images](/chainguard/chainguard-images/about/differences-distroless-dev/) (also known as `-dev` images), suitable for building and running PHP workloads. The `latest-fpm` variant serves PHP applications over FastCGI, while the `latest` variant runs PHP applications from the command line.
 
 In this guide, we'll set up a demo and demonstrate how you can use Chainguard Images to develop, build, and run PHP applications.
 
@@ -126,7 +126,7 @@ In the next step, you'll build the application in a multi-stage Dockerfile.
 
 ## 2. Building a Distroless Image for the Application
 
-We'll now build a distroless image for the application. To be able to install dependencies with Composer, our build will consist of **two** stages. First, we'll build the application using the `dev` image variant, a Wolfi-based image that includes Composer and other useful tools for development. Then, we'll create a separate stage for the final image. The resulting image will be based on the distroless PHP Wolfi image, which means it doesn't come with Composer or even a shell.
+We'll now build a distroless image for the application. To be able to install dependencies with Composer, our build will consist of **two** stages. First, we'll build the application using the `-dev` image variant, a Wolfi-based image that includes Composer and other useful tools for development. Then, we'll create a separate stage for the final image. The resulting image will be based on the distroless PHP Wolfi image, which means it doesn't come with Composer or even a shell.
 
 For reference, here is the content of the included `Dockerfile`:
 

content/chainguard/chainguard-images/getting-started/pytorch/index.md

@@ -105,7 +105,7 @@ data       octopus_whale_penguin_model.pt
 
 ## Manual Steps to Fine-Tune the Model
 
-Below are manual steps to perform the above download and training procedure interactively. You may wish to follow these steps if you need to modify the above for your own use case, if you'd like to better understand the steps involved, or if you have difficulty running the above command in your environment. These steps use `git clone` rather than `curl`. Also note that this manual process uses the `:latest-dev` version of the image, since the `:latest` production image does not include shells such as bash for increased security.
+Below are manual steps to perform the above download and training procedure interactively. You may wish to follow these steps if you need to modify the above for your own use case, if you'd like to better understand the steps involved, or if you have difficulty running the above command in your environment. These steps use `git clone` rather than `curl`. Also note that this manual process uses the `:latest-dev` version of the image, since the `:latest` image does not include shells such as bash for increased security.
 
 In the below steps, the prompt of your host machine will be denoted as `(host) $`, while the prompt of the container machine will be denoted as `(container) $`
 

content/chainguard/chainguard-images/how-to-use/how-to-use-chainguard-images.md

@@ -95,7 +95,7 @@ Specifying the platform will ensure that you're using the desired image and rele
 
 ### Running a Chainguard Image
 
-You can run a Chainguard Image with the `docker run` command. Note that because Chainguard Images are minimalist containers, most of them ship without a shell or package manager. If you would like a shell, you can often use the development image, which is tagged as `:latest-dev` (for example, [Python](https://images.chainguard.dev/directory/image/python/overview?utm_source=cg-academy&utm_medium=website&utm_campaign=dev-enablement&utm_content=edu-content-chainguard-chainguard-images-how-to-use-chainguard-images) has its dev image at `cgr.dev/chainguard/python:latest-dev`). Otherwise, you can work with Chainguard Images in way similar to other images.
+You can run a Chainguard Image with the `docker run` command. Note that because Chainguard Images are minimalist containers, most of them ship without a shell or package manager. If you would like a shell, you can often use the `-dev` image, so named because it's tagged as `:latest-dev`. For example, [Python](https://images.chainguard.dev/directory/image/python/overview?utm_source=cg-academy&utm_medium=website&utm_campaign=dev-enablement&utm_content=edu-content-chainguard-chainguard-images-how-to-use-chainguard-images) has its dev image at `cgr.dev/chainguard/python:latest-dev`. Otherwise, you can work with Chainguard Images in way similar to other images.
 
 Let's run the [Cosign Chainguard Image](https://images.chainguard.dev/directory/image/cosign/overview?utm_source=cg-academy&utm_medium=website&utm_campaign=dev-enablement&utm_content=edu-content-chainguard-chainguard-images-how-to-use-chainguard-images) to check its version.