This repository has been archived on 2024-04-08. You can view files and clone it, but cannot push or open issues or pull requests.
dagger/docs/guides/1205-container-images.md

59 lines
2.3 KiB
Markdown
Raw Normal View History

Add the must-have pages for the Europa release The goal is to capture the shape of the new docs. It is not meant to be final, but it should be as close as possible. We only want the bare minimum for new users that on-board with Dagger Europa. As soon as the new europaSidebar replaces replaces the existing one, the previous docs will still remain available - doc IDs are unique and permanent. We will do this by simply changing the default `slug: /` to point to the Europa Docs entrypoint, which is doc 1200. Helpful Docusaurus link re multiple sidebars: https://docusaurus.io/docs/sidebar/multiple-sidebars The new pages are numbered from `1200` onwards. This is meant to reflect the `0.2.0` Dagger version. This numbering felt more meaningful than just continuing to increment existing numbers. I didn't want to be "wasteful" with the digits and start at `2000`, but that was my first instinct. I am keen on getting this live on https://docs.dagger.io/1200/local-ci. Anything that is not in production, is inventory. Inventory is bad. The goal is to allow anyone that has a link to get a feel for the new docs as soon as possible, so that we can all see how they improve in real-time, and steer them continuously towards the desired state. We should be aware of the timeline, and not muck about, but instead evaluate constantly how close are we to "flipping the switch". Remember, the best releases are those where switches are flipped (e.g. `--europa)`. The feature will have been out there for weeks (maybe even months), improved by talking to users and then one day realising that we are done, and just enabling it by default. It's the same principle behind these docs. Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
2022-02-07 23:16:01 +01:00
---
slug: /1205/container-images
displayed_sidebar: '0.2'
Add the must-have pages for the Europa release The goal is to capture the shape of the new docs. It is not meant to be final, but it should be as close as possible. We only want the bare minimum for new users that on-board with Dagger Europa. As soon as the new europaSidebar replaces replaces the existing one, the previous docs will still remain available - doc IDs are unique and permanent. We will do this by simply changing the default `slug: /` to point to the Europa Docs entrypoint, which is doc 1200. Helpful Docusaurus link re multiple sidebars: https://docusaurus.io/docs/sidebar/multiple-sidebars The new pages are numbered from `1200` onwards. This is meant to reflect the `0.2.0` Dagger version. This numbering felt more meaningful than just continuing to increment existing numbers. I didn't want to be "wasteful" with the digits and start at `2000`, but that was my first instinct. I am keen on getting this live on https://docs.dagger.io/1200/local-ci. Anything that is not in production, is inventory. Inventory is bad. The goal is to allow anyone that has a link to get a feel for the new docs as soon as possible, so that we can all see how they improve in real-time, and steer them continuously towards the desired state. We should be aware of the timeline, and not muck about, but instead evaluate constantly how close are we to "flipping the switch". Remember, the best releases are those where switches are flipped (e.g. `--europa)`. The feature will have been out there for weeks (maybe even months), improved by talking to users and then one day realising that we are done, and just enabling it by default. It's the same principle behind these docs. Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
2022-02-07 23:16:01 +01:00
---
# Building container images
You can use Dagger to build container images, either by executing a Dockerfile, or specifying the build steps natively in CUE. Which method to choose depends on the requirements of your project. You can mix and match builds from both methods in the same plan.
## Executing a Dockerfile
Dagger can natively load and execute Dockerfiles. This is recommended in cases where compatibility with existing Dockerfiles is more important than fully leveraging the power of CUE.
Here's a simple example of a [Dockerfile](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/) build:
```cue file=../tests/core-concepts/container-images/simple/with-dockerfile.cue
```
## Specifying a build in CUE
You can specify your container build natively in CUE, using the official Docker package: `universe.dagger.io/docker`. This is recommended when you don't need to worry about Dockerfile compatibility, and want to take advantage of the full power of CUE and the Dagger APIs.
Native CUE builds have the same backend as Dockerfile builds, so all the same features are available. Since CUE is a more powerful language than the Dockerfile syntax, every Dockerfile can be ported to an equivalent CUE configuration, but the opposite is not true. The following example produces the same image as above.
```cue file=../tests/core-concepts/container-images/simple/build.cue
```
Because this build configuration is pure CUE, it can leverage the full power of Dagger's composition model.
## Automation
Building images in CUE gives you greater flexibility. For example, you can automate building multiple versions of an image, and deploy, all in Dagger:
```cue file=../tests/core-concepts/container-images/template/dagger.cue
```
Now you can deploy all versions:
```shell
dagger do versions
```
Or just build a specific version, without pushing:
```shell
dagger do versions 8.0 build
```
## Multi-stage build
Another common pattern is [multi-stage builds](https://docs.docker.com/develop/develop-images/multistage-build/#use-multi-stage-builds). This allows you to have heavier build images during the build process, and copy the built artifacts into a cleaner and lighter image to run in production.
```cue file=../tests/core-concepts/container-images/multi-stage/dagger.cue
```