Building image from Dockerfile is the easiest way to start using werf in an existing project.
werf.yaml below describes an image named
example related with a project
project: my-project configVersion: 1 --- image: example dockerfile: Dockerfile
To specify some images from one Dockerfile:
image: backend dockerfile: Dockerfile target: backend --- image: frontend dockerfile: Dockerfile target: frontend
And also from different Dockerfiles:
image: backend dockerfile: dockerfiles/DockerfileBackend --- image: frontend dockerfile: dockerfiles/DockerfileFrontend
Images are declared with image directive:
image: <image name>.
The image directive starts a description for building an application image.
The image name is a string, similar to the image name in Docker:
If image only one in the config, it can be nameless:
In the config with multiple, all images must have names:
image: frontend ... --- image: backend ...
An image can have several names, set as a list in YAML syntax (this usage is equal to describing similar images with different names):
You can use image name for most commands to execute ones for specific image(s):
- werf build [IMAGE_NAME…] [options]
- werf publish [IMAGE_NAME…] [options]
- werf build-and-publish [IMAGE_NAME…] [options]
- werf run [options] [IMAGE_NAME] [– COMMAND ARG…]
Also, image name is used for naming when publishing built image into registry (read about it in separate article).
werf as well as Docker builds the image based on a Dockerfile and a context.
dockerfile(required): to set Dockerfile path relative to the project directory.
context: to set build context PATH inside project directory (defaults to root of a project,
target: to link specific Dockerfile stage (last one by default, see
docker build--target option).
args: to set build-time variables (see
docker build--build-arg option).
addHost: to add a custom host-to-IP mapping (host:ip) (see
docker build--add-host option).
network: to set the networking mode for the RUN instructions during build (see
docker build--network option).
ssh: to expose SSH agent socket or keys to the build (only if BuildKit enabled) (see
docker build--ssh option).