joe@/home/joe$ git clone https://github.com/joe/project.git joe@/home/joe$ cd project joe@/home/joe/project$ target/hello ✗ target/hello: No such file or directory joe@/home/joe/project$ make ✗ make: command not found joe@/home/joe/project$ dock hostuser@/project$ make Building... Built 'target/hello' hostuser@/project$ exit joe@/home/joe/project$ target/hello Hello, world!
dock init
Adds dock.yaml and build.Dockerfile
$ dock init rust Skipped './Cargo.toml' Skipped './src' Skipped './src/main.rs' Created './build.Dockerfile' Created './dock.yaml'
dock shell -DWork from within your build enviroment
$ dock shell -D [$] docker build ... [>] Sending build context to Docker daemon [>] ... [>] Successfully tagged org/proj.build:latest ... [$] docker run ... [>] I have no name!@host$ ls [>] build.Dockerfile Cargo.toml dock.yaml src
dockDon't output debugging information
$ cargo run ✗ The program 'cargo' is currently not installed. $ dock I have no name!@host$ cargo run Compiling proj v0.0.1 (/app) Finished dev [unoptimized + debuginfo] target(s) Running `target/debug/proj` hello, world!
The convenience script install.sh can be used to
install pre-built Dock binaries based on your detected
environment. dock can be installed globally by
running sudo sh install.sh.
$ mkdir "$HOME/bin" $ wget install.sh $ sh install.sh --to "$HOME/bin" $ ~/bin/dock --version dock 0.35.6
Pre-built binaries are available on GitHub for certain targets. Other targets supported by cross may be requested.
$ vsn='0.35.6' $ tgt='x86_64-unknown-linux-musl' $ url="https://github.com/ezanmoto/dock/releases/download/$vsn/dock-${vsn}-${tgt}.tar.gz" $ curl -L "$url" | tar -xzC /tmp ... $ install -m 755 /tmp/dock /usr/local/bin $ dock --version dock 0.35.6
cargo can be used to build and install the latest
version of the project. Note that this requires setting the
DOCK_DEFAULT_TEMPLATES_SOURCE
environment variable.
$ export DOCK_DEFAULT_TEMPLATES_SOURCE='git:https://github.com/ezanmoto/dock_init_templates.git:0.1:./templates' $ cargo install --git https://github.com/ezanmoto/dock ... Compiling dock v0.35.6 Finished release [optimized] target(s) Installing /cargo/bin/dock Installed package `dock v0.35.6` $ /cargo/bin/dock --version dock 0.35.6
dock always rebuilds images before running commands
in them. This keeps you in sync with your team and your current
branch automatically.
You can easily mount your local user, group and project directory
to make it feel like you're building locally, which avoids the
pitfalls of running as root in your build containers.
dock allows "nesting" of bind mounts, so that bind
mounts can even be used in your CI environment for speeding up
builds, as described in Docker
for the Build Process.
Dock's special cache volumes help you share reusable caches
between your build environments, while also making them usable by
non-root users.
Dock is a relatively thin wrapper around the Docker CLI. Use
-D with most subcommands to see what
dock is running under the hood.
shell
Services you run while you're in dock shell are
automatically available on localhost.
Running commands in the same containerised environments locally and in the build pipeline minimises differences, and can dramatically help with debugging both.
As with the build pipeline, having team members on the exact same versions of system dependencies helps to avoid using features that not all members have, like an OS-level lock file.
Onboarding onto a new project can be as simple as running
dock, because you now have a shell with access to all
the system dependencies of the project.
Running a different version of your OS to your CI can make it easy to depend on local functionality that doesn't exist remotely, but developing in containers can help to avoid this.
Developers that still want to install dependencies locally can
follow the steps laid out in the build.Dockerfile,
rather than steps
defined manually in the README.
Having your environment definition committed as code means that you can version your build environment in the same way as other dependencies, keeping your team and CI in sync automatically.
Dock is primarily intended to be used as part of your local development process. It should ideally be used in your team's centralised build pipeline too, to build artefacts and images for production use.
Note that Dock commands shouldn't be used to directly run production
services (by using dock run-in prod-env: serve, for
example). This is because the features that Dock provides are primarily
for speeding up development, particularly through the use of bind
mounts (volumes are generally more appropriate for production
scenarios). Instead, a dedicated container orchestrator like Docker
Compose should be used instead of Dock for running production
workloads.
dockerized is a tool for seamlessly executing commands in a container.
Where Dock is a thin wrapper around the Docker CLI, dockerized is a thin wrapper around Docker Compose, which is used to achieve similar functionality. The goals and benefits of the two tools are largely the same, they mostly differ in terms of implementation. The dockerized documentation in particular provides a great outline of why you should keep your build dependencies in a Dockerfile, as well as a list of manual alternatives and their downsides.
The use of Docker Compose by dockerized allows orchestration of multiple services using the standard compose file. dockerized also has support for VSCode Remote Containers by default, and has a number of "starter kits" for popular languages, and VSCode. dockerized also provides a mechanism for pushing and pulling the build environment itself, to speed up the creation of build environments that involve steps with a large latency.
Dock provides a number of convenience features that aren't available
in Docker Compose at present, including mounting the local user and
group (so that commands aren't run as root), simplified
mounting of the host Docker engine, nested bind mounts, and cache
volumes (which are slightly different to the standard volumes that
Docker provides). Dock also provides a dock
rebuild subcommand, that can be used to keep your images
up-to-date even when you're not using the dock run-in
and dock shell subcommands, which can pair conveniently
with the use of Docker Compose (and dockerized itself, for that
matter).