{"id":40607276,"url":"https://github.com/efrecon/dew","last_synced_at":"2026-01-21T05:04:44.992Z","repository":{"id":36964899,"uuid":"360335275","full_name":"efrecon/dew","owner":"efrecon","description":"Run everything in (Docker) containers","archived":false,"fork":false,"pushed_at":"2025-04-28T05:57:21.000Z","size":276,"stargazers_count":8,"open_issues_count":4,"forks_count":0,"subscribers_count":2,"default_branch":"main","last_synced_at":"2025-04-28T06:34:06.866Z","etag":null,"topics":["containers","development-environment","docker"],"latest_commit_sha":null,"homepage":"","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/efrecon.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":".github/FUNDING.yml","license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null},"funding":{"github":["efrecon"]}},"created_at":"2021-04-21T23:33:47.000Z","updated_at":"2025-04-28T05:57:25.000Z","dependencies_parsed_at":"2023-01-17T09:03:36.013Z","dependency_job_id":"9d2f4940-43a8-40bf-9a31-6311f8fe2659","html_url":"https://github.com/efrecon/dew","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/efrecon/dew","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/efrecon%2Fdew","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/efrecon%2Fdew/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/efrecon%2Fdew/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/efrecon%2Fdew/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/efrecon","download_url":"https://codeload.github.com/efrecon/dew/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/efrecon%2Fdew/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28627388,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-21T04:47:28.174Z","status":"ssl_error","status_checked_at":"2026-01-21T04:47:22.943Z","response_time":86,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["containers","development-environment","docker"],"created_at":"2026-01-21T05:04:14.914Z","updated_at":"2026-01-21T05:04:44.978Z","avatar_url":"https://github.com/efrecon.png","language":"Shell","funding_links":["https://github.com/sponsors/efrecon"],"categories":[],"sub_categories":[],"readme":"# Docker EveryWhere, `dew`\n\nWe are past 2020! Docker can be used to provide the same working environment\nacross platforms. `dew` aims at development workflows consisting of Docker\ncontainers based on images with the tooling of your requiring. These containers\nwill run from within the current directory and as your current user inside the\ncontainer. In most cases, this allows for transient environments, as all that is\nrequired on the host is a Docker daemon and images that can be garbage collected\nonce done (containers are automatically removed once they have ended).\n\nRunning `dew` increases security by encapsulating only the relevant part of the\nfile system required for a workflow. In addition, it should save you from\n\"dependency hell\". You should be able to keep OS installation to a minimal and\nrun most activities from within containers in a transparent way. These\ncontainers will have your shell code, your configuration, but all binaries and\ndependencies will remain in the container and disappear automatically once done.\n\nFor the technically inclined, `dew` is a shortcut to the command below.\nActually, the [implementation](#implementation) is a bit more complex, but in\nthe same spirit:\n\n```shell\ndocker run \\\n  -it --rm \\\n  -v $(pwd):$(pwd) \\\n  -w $(pwd) \\\n  -u $(id -u):$(id -g) \\\n  -v /var/run/docker.sock:/var/run/docker.sock \\\n  --network host \\\n  xxx\n```\n\nThis script takes some inspiration from [lope] with the addition of being able\nto read configurations for known environments. This minimises typing and\nautomates all the necessary command-line options for making a given environment\npossible. Configurations are simply `env` files placed: in a sub-directory of\nthe current directory called `.dew.d`, in a sub-directory of the\n`$XDG_CONFIG_HOME` directory, or under the [`config`](./config/) directory of\nthis repository. To get a list of known configurations, run `dew` with the `-l`\noption.\n\nWhen `$0` -- the main progam -- is a symbolic link to `dew`, `dew` will\nautomatically use the basename of the link as the name of the configuration to\nlook for. It will not parse **any** argument, instead all arguments are passed\nto the Docker image specified by the configuration that it finds. You *can* use\nthe environment variables starting with `DEW_` if you want to alter options.\n\n  [lope]: https://github.com/Crazybus/lope\n\n**Note**: This project uses git [submodules], use one of the two commands to\nmake sure you have a copy of the submodules. Without the modules, the main\nscript will not even start!\n\n```shell\ngit clone --recursive https://github.com/efrecon/docker-images.git\ngit submodule update --init --recursive\n```\n\nTo catch up with changes, run the following:\n\n```shell\ngit submodule update --init --recursive\n```\n\n  [submodules]: https://git-scm.com/book/en/v2/Git-Tools-Submodules\n\n## Examples\n\nAll these examples suppose that you have made `dew.sh` available from your\n`$PATH`. They will also work if you symlink `dew` to a place where you have this\nrepository installed, and arrange for the `dew` symlink to be in your `$PATH`.\nTo make it quicker to type, you probably want to call the symbolic link `dew`\ninstead of `dew.sh`.\n\n### Busybox\n\nTo get a busybox shell in the current working directory, in order to more easily\ntest POSIX compliance of your scripts, or their ability to run in an embedded\nsystem, you could run the following command:\n\n```shell\ndew.sh busybox\n```\n\nThis simple command builds upon many of the \"good\" defaults. It will:\n\n+ Give you an interactive `ash` prompt with the content of the current directory\n  visible. `ash` is picked up from a list of plausible shells, as one existing\n  in `busybox`.\n+ Forbid access to parent directories, or directories elsewhere on the disk.\n  This is a security feature.\n+ Arrange for the container to run the shell with your user and group ID, so\n  file access, creation and permissions work as expected.\n+ Automatically forward the values of most of your environment variables to the\n  container.\n+ Arrange for the container to have a minimal environment mimicing your local\n  environment: there will be a `$HOME` directory, the same as yours. There will\n  be a user and a group, with the same IDs as yours.\n\nTo verify this, assuming that you have a copy of this repository and its\n[submodules] at `/home/emmanuel/dev/foss/dew` you could run the following\ncommand from that directory.\n\n```shell\n./dew.sh busybox find $HOME -type d | grep -v .git\n```\n\nThis should output the following. `.git` information has been removed to keep\nthis output sizeable. You can verify that only the relevant parts of the\nfilesystem have been made available to the container, but also that the\ncontainer has accessed to the `$HOME` variable and that it matches your own\n`$HOME` on the host.\n\n```text\n/home/emmanuel\n/home/emmanuel/dev\n/home/emmanuel/dev/foss\n/home/emmanuel/dev/foss/dew\n/home/emmanuel/dev/foss/dew/libexec\n/home/emmanuel/dev/foss/dew/libexec/docker-rebase\n/home/emmanuel/dev/foss/dew/libexec/docker-rebase/lib\n/home/emmanuel/dev/foss/dew/libexec/docker-rebase/lib/mg.sh\n/home/emmanuel/dev/foss/dew/libexec/docker-rebase/lib/mg.sh/spec\n/home/emmanuel/dev/foss/dew/libexec/docker-rebase/lib/mg.sh/spec/support\n```\n\n### Alpine\n\nRunning the following command provides more or less the same prompt as above.\nNote however that, since the default is to run impersonated as yourself, you\nwill end up having an Alpine promt where you cannot install additional software\n(as you will not be able to `sudo`).\n\n```shell\ndew.sh alpine\n```\n\nTo run as root, do the following instead:\n\n```shell\ndew.sh -r alpine\n```\n\nWithout being root, and as long as your local user on the host has access to the\nDocker daemon, you can give yourself access to the host's Docker daemon and see\nother containers that are running by running the following command:\n\n```shell\ndew.sh --docker alpine\n```\n\nIn practice this will download a version of the Docker client on your local\nmachine, place the client in a sub-directory of the XDG cache (i.e. as specified\nby `$XDG_CACHE_HOME` or the default `${HOME}/.cache`) and mount the binary into\nthe Alpine Docker container. Go binaries are statically compiled, making this\npossible across distributions and libc implementations. In addition, `dew` will\nhave arranged for the impersonated user within the container to be a member of\nthe `docker` group, under the same ID as the local `docker` group as associated\nto the UNIX domain socket at `/var/run/docker.sock`.\n\nFrom within the Alpine container, the following command will therefore work as\nexpected and show all running containers on the host. One of these containers\nwill be your container. It will have been automatically be named to\n`dew_alpine_` followed by the PID of the `dew` process at the time of its\ncreation. You should even be able to kill yourself by removing the container\nwith the Docker CLI!\n\n```shell\ndocker ps\n```\n\nIf you run the command from the root directory of this repository, you can even\nstart yet another `dew` environment from the prompt within the first `dew`\ncontainer. In other words, from the Alpine prompt in the container, running the\nfollowing command will open yet another clean environment in another container.\nTo verify this, you should see that running `dew.sh` downloads a new copy of the\nDocker client, as it does not exist in the cache from within the first\ncontainer.\n\n```shell\ndew.sh --docker alpine\n```\n\n### Python\n\nTo get an interactive python, you could run the following command:\n\n```shell\ndew.sh python\n```\n\nSetting up python uses a specific environment configuration\n[file](./config/python.env). It specifies a number of variables that will be\nused by `dew` when creating the container. In practice, this sets the shell to\nuse for the environment to `-`, which is understood by `dew` as running the\ndefault `python` image from the Docker hub, but as your regular user.\n\n### Node\n\nTo get a bash prompt where you can run both `npm` and `node`, run the following\ncommand. The entrypoint for the node image is `node`, but the default for `dew`\nwhen running with impersonation is to inject its own [`su.sh`](./bin/su.sh)\nscript as an entrypoint. The script will ensure a minimal HOME environment for a\nuser named after yours. This is why the following command provides a bash\nprompt, rather than a `node` prompt. In that specific case, you might also\nnotice that you might become the user called `node` (and not your username).\nThis is because the default Docker node image already has a user at uid `1000`\nwith the name `node`.\n\n```shell\ndew.sh node\n```\n\nIf you instead want to get an interactive `node` prompt, run the following. This\nsuppresses injection of [`su.sh`](./bin/su.sh) as described above, reverting to\nthe regular behaviour.\n\n```shell\ndew.sh -s - node\n```\n\n### Tcl\n\nIn the same vein, getting an interactive Tcl prompt is as easy as running the\nfollowing command.\n\n```shell\ndew.sh tclsh\n```\n\nThis uses a slightly more advanced environment configuration\n[file](./config/tclsh.env). The configuration arranges for a user-level specific\n[entrypoint](./config/tclsh.sh) to be injected into the container and used as\nthe shell. The purpose of this is to be able to provide the user with a\n`.tclshrc` file in its `$HOME` directory. The `.tclshrc` is picked from its\ndefault location in the [image][mini-tcl] and arranges for a readline-capable\nTcl prompt with a coloured prompt.\n\n  [mini-tcl]: https://hub.docker.com/r/efrecon/mini-tcl/\n\n### Kubernetes\n\nTo operate against a Kubernetes cluster, you could run a command similar to the\nfollowing one. The command uses yet another configuration\n[file](./config/kubectl.env), this time with the main goal of passing your\n`$HOME/.kube/config` file to the container.\n\n```shell\ndew.sh kubectl get pods --all-namespaces\n```\n\n### lazydocker\n\nTo run lazydocker to analyse what is currently running at your local Docker\ndaemon, run the following command:\n\n```shell\ndew.sh --docker --root --shell - lazyteam/lazydocker\n```\n\nAs this is almost too long, even when using the short options, there is a\nready-made configuration for [lazydocker](./config/lazydocker.env). The\nconfiguration arranges to run under your account with impersonation and for\nconfiguration settings to be saved at their standard location in your `$HOME`\ndirectory. This requires [rebasing](#dew_rebase) the image on top of\n`busybox:latest`. Instead of the longer command above, you should be able to\nrun:\n\n```shell\ndew.sh lazydocker\n```\n\n## Command-Line Options\n\n`dew` offers a number of command-line options, possibly followed by a\ndouble-dash `--` to mark the end of the options, followed by the name of a\nDocker image (or the name of a tailored environment found under the\nconfiguration path), followed by arguments that will be passed to the Docker\ncontainer at its creation (the `COMMAND` from a Dockerfile). Pass the option\n`--help` to get a list of known options.\n\nProvided the first argument after the (optional) `--` is `XXX`, it will be\nunderstood as follows:\n\n+ If a file called `Dockerfile.XXX`, or `XXX.Dockerfile`, or `XXX.df` is found\n  under the configuration path `DEW_CONFIG_PATH`, that file will be used to\n  build a local Docker image called `github.com/efrecon/dew/XXX` -- the prefix\n  is actually controlled by `DEW_NAMESPACE`. `dew` will rebuild a new image only\n  whenever a change has been detected on the Dockerfile.\n+ If a file called `XXX` or `XXX.env` is found under the configuration path\n  `DEW_CONFIG_PATH`, that file will be used to set any of the environment\n  variables described below. Note that it is possible to combine this behaviour\n  with the Dockerfile behaviour above.\n+ If none of the above was true, `XXX` is understood as the name of a local or\n  remote Docker image.\n\n## Environment Variables\n\n`dew` can also be configured using environment variables, these start with\n`DEW_`. Command-line options, when specified, have precedence over the\nvariables. Apart from empty-lines and comments, the `DEW_`-led variables are the\nonly variables that can be set in the environment configuration files found\nunder the configuration path.\n\n### `DEW_CONFIG_PATH`\n\nThis variable is a colon separated list of directories where `dew` will look for\nenvironment configuration files, i.e. files which basename matches the first\ncommand-line argument after all the options, or Dockerfiles. The default for the\nconfiguration path is the directory `dew` under `$XDG_CONFIG_HOME`, followed by\nthe `config` directory under this repository. When `XDG_CONFIG_HOME` does not\nexist, it defaults to `$HOME/.config`.\n\n### `DEW_SOCK`\n\nThis variable contains the location of the Docker UNIX domain socket that will\nbe passed to the container created by `dew`. The default is to pass the socket\nat `/var/run/docker.sock`. When the value of this variable is empty, the socket\nwill not be passed to the container. Note that this is not the same as the\n[`DEW_DOCKER`](#dew_docker) variable. Both need to be set if you want a Docker\nCLI in your container.\n\n### `DEW_BLACKLIST`\n\nThis variable is a comma-separated list of environment variables that will\n**not** be passed to the container where impersonation is turned on (see\n[`DEW_IMPERSONATE`](#dew_impersonate)). The default is\n`SSH_AUTH_SOCK,TMPDIR,PATH`.\n\n### `DEW_IMPERSONATE`\n\nThis variable is a type or a boolean. When set to `1`, the default,\nimpersonation will happen, i.e. the process or interactive prompt inside the\ncontainer will run under a user with the same user and group identifiers as the\nones of the calling user. In addition, in interactive containers, the user\ninside the container will be given the same `HOME` directory as the original\nuser, albeit empty (except perhaps for the current path, see\n[`DEW_MOUNT`](#dew_mount)). Impersonation works by running the container as\n`root`, but injecting an impersonation script that will setup a minimal\nenvironment inside the container before becoming to relevant user and group.\n\nWhen the variable is set to `minimal`, minimal impersonation will happen\ninstead. This means that the identifier of the first regular user present inside\nthe image will be used for impersonation. The container is then run using the\n[`--user`][user] option, but [`fixuid`][fixuid] is injected and used to arrange\nfor proper access rights for files.\n\n  [user]: https://docs.docker.com/engine/reference/run/#user\n  [fixuid]: https://github.com/boxboat/fixuid\n\n### `DEW_INTERACTIVE`\n\nThis variable is a boolean. When set to 1, the default, interaction will be\nenabled within the container. In practice, this means that the Docker run\ncommand will use the options `-it -a stdin -a stdout -a stderr`. It is possible\nto turn this off, but re-adding a single `-i` through the\n[`DEW_OPTS`](#dew_opts) variable for proper pipe support. See\n[bat](./config/bat.env) for an example.\n\n### `DEW_DOCKER`\n\nThis variable is a boolean. When set to 1, a version of the Docker client should\nbe injected into the destination container. The default is `0`, i.e. no Docker\nCLI available. Note that you need [`DEW_SOCK`](#dew_sock) to point to the UNIX\ndomain socket to arrange for the Docker CLI client in the container to be able\nto access the host's Docker daemon. When impersonating, user inside the\ncontainer will be made a member of the `docker` group in order to have the\nproper permissions.\n\n### `DEW_MOUNT`\n\nThis variable expresses the number of levels up the directory hierarchy,\nstarting from the current one, should be mounted into the container. A negative\nnumber turns off the function entirely. When positive, the working directory in\nthe container maps to the current directory. Setting this to strictly positive\nvalues will facilitate accessing (development) files upwards in the tree. In\nother words:\n\n+ Setting `DEW_MOUNT` to `0` (the default) mounts the current directory inside\n  the container and makes it the working directory.\n+ Setting `DEW_MOUNT` to `1` mounts the parent of the current directory inside\n  the container, and makes the current directory the working directory. This\n  enables the container to access all files and directories contained in the\n  parent directory.\n\n### `DEW_MOUNTS`\n\nThis variable should contain a space-separated list of bindmount specifications,\nfrom the host into the container. Each specification is modelled after the `-v`\n[option][mount-vol] of the Docker client. Mount specifications are separated by\nthe colon `:` sign and will contain in order:\n\n+ The source directory on the host.\n+ The destination directory into the container. When empty, this will\n  automatically be initialised the the same as the source directory on the host.\n+ A list of options, blindly passed to the `-v` option. When running with\n  `podman`, the `Z` option will automatically be added.\n\nNote that in the content of this variable, any string named after one of the\ndocumented [variables](#variables-accessible-to-resolution), but surrounded by\n`%`, e.g. `%DEW_SHELL%`, will be replaced by the value of that variable.\n\n  [mount-vol]: https://docs.docker.com/reference/cli/docker/container/run/#volume\n\n### `DEW_OPTS`\n\nThe content of this variable is blindly passed to the `docker run` command when\nthe container is created. It can be used to pass further files or directories to\nthe container, e.g. the k8s configuration file, or an rc file.\n\nNote that in the content of this variable, any string named after one of the\ndocumented [variables](#variables-accessible-to-resolution), but surrounded by\n`%`, e.g. `%DEW_SHELL%`, will be replaced by the value of that variable.\n\n### `DEW_SHELL`\n\nThis variable can contain the path to a shell that will be run for interactive\ncommands. The default is to have an empty value, which will look for the\nfollowing possible shells in the container, in that order: `bash`, `ash`, `sh`.\n\n### `DEW_DOCKER_VERSION`\n\nThis variable is the version of the Docker client to download and inject in the\ncontainer when running with the `-d` (`--docker`) command-line option, or when\nthe [`DEW_DOCKER`](#dew_docker) variable is set to `1`. When empty, the default,\nthe latest version of the Docker client will be downloaded. Check for new\nversions only happen every [`DEW_BINCACHE_VERCHECK`](#dew_bincache_vercheck)\nseconds.\n\n### `DEW_INSTALLDIR`\n\nThis variable is the directory where to install binaries inside the container.\nThis defaults to `/usr/local/bin`, a directory which is part of the default\n`PATH` of most distributions.\n\n### `DEW_REBASE`\n\nThis variable will [rebase] the main image passed as the first argument on top\nof the image given to the option. This can be handy when running with slimmed\ndown images that only contain relevant binaries, and when you, for example,\ndesire a shell and related utilities at an interactive prompt in such an image.\nRebasing will generate a new image, and this will happen once and only once per\npair of images.\n\n  [rebase]: https://github.com/efrecon/docker-rebase\n\n### `DEW_XDG`\n\nWhen the value of this variable is not empty, `dew` will create 4 directories\nunder the [XDG] standard directories, named after the value of that variable\n(i.e. sub-directories of `$XDG_DATA_HOME`, `$XDG_CONFIG_HOME`, `$XDG_STATE_HOME`\nand `$XDG_CACHE_HOME`). Each directory that was successfully created, will be\nmounted into the container for read and write. Using sub-directories is\ncompatible with most tools and enforces configuration isolation as the binaries\nrunning in the container will not be able to read any other XDG configuration\nfiles than the selected ones.\n\n  [XDG]: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html\n\n### `DEW_PATHS`\n\nThis variable should contain a space-separated list of path specifications.\nThese specifications will point to files and/or directories that will be created\nbefore the container is created. This can be used in addition to the\n[`DEW_XDG`](#dew_xdg) variable for hidden setting files and similar. Path\nspecifications should contain the following items, separated by the colon `:`\nsign:\n\n+ The path to the file or directory to create (mandatory)\n+ The type of the path: `f` or `-` for a file, `d` for a directory. When empty,\n  the default, a file will be created through `touch`.\n+ A template (file or directory) to initialise the content of the file or\n  directory. In this specification `%` enclosed variable\n  [names](#variables-accessible-to-resolution) will be replaced by their\n  content.\n+ The access specification for the path, compatible with the `chmod` command,\n  e.g. `0700` or `ug+rw`. When empty, the default, no `chmod` will be performed\n  and the file or directory will be created with the user account's default\n  mask.\n+ The owner of the file (a name or an integer). When empty, the default, the\n  owner will not be changed and be the user running the script.\n+ The group owner of the file (a name or an integer). When empty, the default,\n  the group will not be changed and be the one of the user running the script.\n\n### `DEW_RUNTIME`\n\nThis variable should contain the name of a runtime client able to create OCI\ncontainers using the docker CLI command-line options. By default, this is an\nempty string, in which case the first existing client out of the list contained\nin the `DEW_RUNTIMES` (note the terminating `S`) will be picked. `docker` is\nfirst in this list for backwards compatibility.\n\n### `DEW_INJECT`\n\nThis variable implements a single `RUN` command from a Dockerfile on the cheap.\nThe command that it contains will be first used as the entrypoint on the image\npointed at by the `DEW_IMAGE` variable (or corresponding command-line option).\nOnce done, a snapshot of the resulting container will be stored in a local\nimage, using a tag that uniquely depends on the content of the command. Then,\neverything will proceed as described in this manual, but using the new image.\nImage generation will only happen if the content of the command changes. When\nthe command is a valid (local) path, its content will be used instead.\n\nNote that in the content of this variable, any string named after one of the\ndocumented [variables](#variables-accessible-to-resolution), but surrounded by\n`%`, e.g. `%DEW_SHELL%`, will be replaced by the value of that variable.\n\n### `DEW_INJECT_ARGS`\n\nThis variable contains arguments that are blindly passed to the\n[injected](#dew_inject) command at the time of image creation. This facilitates\nthe reuse of the same injected command, with varying arguments. You could, for\nexample, reuse a command that performs generic package installation and give it\nvarying packages for the implementation of a container.\n\nNote that in the content of this variable, any string named after one of the\ndocumented [variables](#variables-accessible-to-resolution), but surrounded by\n`%`, e.g. `%DEW_SHELL%`, will be replaced by the value of that variable.\n\n### `DEW_FEATURES`\n\nThis variable should contain a space separated list of features that each\ncontainer will be provided with. Features are keywords in uppercase and their\ndefinition comes from the file pointed at by the `DEW_FEATURES_CONFIG` variable.\nFeatures are the combination of one or several options and flags to the `run`\ncommand of `docker` or any other supported container runtime.\n\n### `DEW_FEATURES_CONFIG`\n\nThis variable points to a file in `.env` format and containing the definition of\neach recognised feature that can be provided as a keyword in the `DEW_FEATURES`\nvariable. The default location for this file is inside the `etc` subdirectory of\nthe main repository.\n\n### `DEW_BINCACHE_VERCHECK`\n\nWhen versions of binary dependencies are checked, i.e. whenever the specified\nversions for these binaries are empty, `dew` will only check if a new version is\navailable every `DEW_BINCACHE_VERCHECK` seconds. The default is 3 days.\n\n### `DEW_BINCACHE_EXPIRE`\n\n`dew` keeps versions of binary dependencies in the XDG cache.\n`DEW_BINCACHE_EXPIRE` is the number of seconds after which old binaries are\nevicted from the cache. The default is 41 days.\n\n## Variables Accessible to Resolution\n\nThe variables accessible are all the variables starting with `DEW_` and\ndescribed in the section [above](#environment-variables). In addition, it is\npossible to use, when relevant:\n\n+ `DEW_CONFIGDIR`: The directory hosting the `.env` configuration file.\n+ `DEW_ROOTDIR`: The directory hosting the main `dew.sh` script (resolved).\n\n## Implementation\n\nIn many cases, this script goes a few steps further than the `docker run`\ncommand highlighted in the introduction.\n\nFirst of all, in encapsulates all processes running in the container around\n`tini` using the `--init` command-line option of the Docker `run` sub-command.\nThis facilitates signal handling and ensures that all sub-processes will\nproperly terminate without waiting times.\n\nSecond, it pushes timezone information from the host into the container for\naccurate time readings.\n\nThird, and most importantly, `dew` will often not directly add the `--user`\noption to the `run` subcommand, but still ensures that the process(es) is/are\nrun under your user and group. To this end, `dew` injects a\n[su](./bin/su.sh)-encapsulating script into the container and arranges for that\nscript to be run as the entrypoint. The script will perform book-keeping\noperations such as creating a matching user and group in the \"OS\" of the\ncontainer, including a home at the same location as yours. The script will also\nensure that your user inside the container is a member of the `docker` group to\nfacilitate access to the mounted Docker socket. Once all book-keeping operations\nhave been performed, the script becomes \"you\" inside the container and execute\nall relevant processes under that user with `su`.\n\nEncapsulated behind the main `su`, processes should see an empty (but existing!)\n`$HOME`, apart from the current directory where the `dew` container was started\nfrom. That directory will be populated with all files accessible under that part\nof the filesystem tree. Some tools require more files to be accessible for\nproper operation (configuration files, etc.). In that case, you should be able\nto add necessary files through passing additional mounting options to the docker\n`run` subcommand, e.g. [kubectl](./config/kubectl.env) or\n[lazydocker](./config/lazydocker.env). The [su](./bin/su.sh)-encapsulating\nscript requires a number of common Linux utilities to be present in the target\ncontainer. When running with slimmed down images, you can make sure to provide\nsuch an environment through the `--rebase` option or its equivalent\n[`DEW_REBASE`](#dew_rebase) variable.\n\nIt is possible to make use of the `--user` option of the `run` subcommand when\nsetting the [`DEW_IMPERSONATE`](#dew_impersonate) variable to `minimal`. In that\ncase, the [su](./bin/su.sh) script will not be injected.\n\n## Requirements\n\n`dew` has minimal requirements and is implemented in pure POSIX shell for\nmaximum compatibility across platforms and operating systems. `dew` only uses\nthe command-line options of `sed`, `grep` etc. that available under their\n`busybox` implementation. When creating users and groups, [`su.sh`](./bin/su.sh)\ntries to use the tools available in the base OS used by the container. Finally,\nwhen [rebasing](#dew_rebase) is necessary, [rebase.sh][rebase] will require `jq`\nto be installed on the host system.\n\n## History and Breaking Changes\n\nFor a short time period, `dew` supported a `DEW_NETWORK` environment variable\n(and corresponding `--network` option). This has been removed in favour of the\n`DEW_FEATURES` environment variable.\n\nA number of `.env` files contain references to `DEW_OPTS` for mounting extra\ndirectories/files into the container. It is usually a better idea to use the\n`DEW_MOUNTS` variable instead, as it will be aware of the differences between\n`docker` and `podman`.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fefrecon%2Fdew","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fefrecon%2Fdew","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fefrecon%2Fdew/lists"}