metaswitch/floki

Launch containers to help build your software

floki's Issues

Environment variables are not set in the `dind` container

floki sets up some environment variables by default, but doesn't set these in the docker-in-docker container.

Possibly a good chance to unify the dind and standard container runner code a little.

Are there nice ways to get `git` (with submodules) working inside containers

e.g. git submodule update --init is bound to fail since it uses absolute paths.

Allow relative paths for mounting volumes

It would be useful to be able to mount a volume from the current directory rather than specifying an absolute path with:

`docker_switches:

• -v
• /absolute/path/to/kube/config:/root/.kube`

Floki is intended to create reproducible containers with the minimum amount of pre-setup. By only allowing absolute paths in volume mounting, a difference in behaviour is created if another user has a different file structure.

Floki doesn't wait for dind service to be ready

Since updating to use the latest Docker in Docker image rather than stable-dind I have noticed that running Docker commands can fail with a race condition with the adjacent DinD container.
The error I get is as follows

docker: Cannot connect to the Docker daemon at tcp://floki-docker:2375. Is the docker daemon running?.

This is hit ~10 seconds after the DinD container is started.

If I add an arbitrary 30 second delay before starting the docker build the dind container appears to be ready and the build is successful.

Could there be a check added when running with dind: true or a specified DinD image to verify that the docker service is ready?

Add `announcer` support for floki Slack

We should be able to steal the implementation from https://github.com/Metaswitch/announcer/blob/master/after_deploy.sh and announce new releases to the floki Slack channel.

use releases

At present, contributors must bump versions, and the Contributing lifecycle needs to be linearized/special treatment

Tag releases to improve this

Add privileged option

--privileged is the only Docker switch currently needed by our build process in floki. With the recent change to require the "local" option if Docker switches are used it would be useful if that could be an option instead.

sh should be the default shell

Because POSIX

Non-root users are not guaranteed a writable home directory

If you set forward_user: true without any further configuration, the user inside the container has no name and its home is the root directory:

I have no name! [ /src ]$ ls -l | head -n 2
total 228
-rw-r--r-- 1 1000 1000 97758 Oct 24 11:26 CHANGELOG.md
I have no name! [ /src ]$ echo $HOME
/
I have no name! [ /src ]$ ls -ld $HOME
drwxr-xr-x 1 root root 4096 Oct 25 10:45 /

Because the user doesn't have write permissions for its $HOME, tools that try to create config or cache files or directories in $HOME do not work. For example, az-cli and docker.

I have no name! [ /src ]$ az login
Traceback (most recent call last):
  File "/usr/lib/python3.9/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/opt/python/venvs/azure-cli/lib/python3.9/site-packages/azure/cli/__main__.py", line 39, in <module>
    az_cli = get_default_cli()
  File "/opt/python/venvs/azure-cli/lib/python3.9/site-packages/azure/cli/core/__init__.py", line 895, in get_default_cli
    from azure.cli.core.azlogging import AzCliLogging
  File "/opt/python/venvs/azure-cli/lib/python3.9/site-packages/azure/cli/core/azlogging.py", line 30, in <module>
    from azure.cli.core.commands.events import EVENT_INVOKER_PRE_CMD_TBL_TRUNCATE
  File "/opt/python/venvs/azure-cli/lib/python3.9/site-packages/azure/cli/core/commands/__init__.py", line 25, in <module>
    from azure.cli.core.extension import get_extension
  File "/opt/python/venvs/azure-cli/lib/python3.9/site-packages/azure/cli/core/extension/__init__.py", line 18, in <module>
    az_config = CLIConfig(config_dir=GLOBAL_CONFIG_DIR, config_env_var_prefix=ENV_VAR_PREFIX)
  File "/opt/python/venvs/azure-cli/lib/python3.9/site-packages/knack/config.py", line 40, in __init__
    ensure_dir(config_dir)
  File "/opt/python/venvs/azure-cli/lib/python3.9/site-packages/knack/util.py", line 115, in ensure_dir
    raise e
  File "/opt/python/venvs/azure-cli/lib/python3.9/site-packages/knack/util.py", line 112, in ensure_dir
    os.makedirs(d)
  File "/usr/lib/python3.9/os.py", line 225, in makedirs
    mkdir(name, mode)
PermissionError: [Errno 13] Permission denied: '/.azure'

It's possible to work around this as follows, but it's hacky. It would be nice if floki guaranteed you a writable home directory.

docker_switches:
  - -e
  - HOME=/tmp/home
forward_user: true
init:
  - mkdir $HOME

Move from Travis CI to Github Actions

Apparently Github Actions are the new hotness - perhaps it's time to look at moving from Travis CI to Github.

It'll probably make the pages task a lot easier!

Rework quicli::prelude::* imports

Using quicli::prelude::* everywhere isn't ideal

Discussion: Separation of floki into library and binary

In order to make floki easier to test on the Rust side, it might make sense to split floki into a library portion and a binary portion. This issue is to track what code would be in which part.

My naive first take on this:

• binary:

  • command line parsing

• library:

  • everything else

Would be interested in hearing thoughts... @rlupton20?

Add docs for `cargo install floki`

Floki is now installable from cargo; we should add some docs for cargo install floki --locked

Enforce code formatting in CI

Floki does not cope well with containers with custom entry points

I have the following config file
image: prom/prometheus:v2.22.1 shell: /bin/sh

The prometheus container has a custom entry point which results in floki being unable to start this container

developer@PC6114:~/gitlab/platform.core/simon-simpl-k8s$ floki -c floki/validate_alerts.yaml Error parsing commandline arguments: unexpected /bin/sh prometheus: error: unexpected /bin/sh 10:52:25 [ERROR] A problem occured: Running container failed: docker run exited with return code 1

However, just running docker exec works fine by setting the entrypoint

developer@PC6114:~$ docker run -it --entrypoint /bin/sh -v $PWD:/src -w /src prom/prometheus:v2.22.1 /src $

Move errors nearer to usage sites

Also look at failure::format_err, to remove unnecessary error types

Publish to crates.io

Better ergonomics for aliases

It would be nice to have a more ergonomic way to configure shell aliases. Maybe something like

aliases:
  - name: build
    command: make
  - name: clean
    command: make clean

Much of Floki's function is hard to test in UT

Floki mostly consists of:

• A command-line interface;
• A series of subshell commands.

Neither are covered in UT, and by their nature aren't easy to cover with UTs either. This means it's easy to break Floki and have all UTs continue to pass.

Having some FV-style testing of Floki as a whole would be useful for catching this class of bugs, and likely more useful in general than fairly narrow-scoped UTs.

Better ergonomics for passing through environment variables

I would like to propose an enhancement to floki to more easily allow existing environment variables to be passed through from the invoking environment to the floki docker container.

I have increasingly been coming across situations which require authentication, where credentials are typically provided via env vars. I therefore want to make it easy to pass these env vars through from a developer's environment into a floki container.

This is currently possible via docker_switches:

docker_switches:
- -e
- MY_REPO_PASSWORD
- -e
- MY_PAT_TOKEN
...etc

However, this is a bit clunky, particularly if you want to pass multiple variables. It is also potentially non-trivial to update this list with automated tools if you want to add/remove entries.

I therefore propose adding a new key env, which simply takes a list of environment variable names to pass through. This would be expanded internally to a series of -e <env_var_name> parameters for the docker run invocation. Example:

env:
- MY_REPO_PASSWORD
- MY_PAT_TOKEN
...etc

Thoughts?

I'm happy to make the code changes if we can agree that this is a desirable feature.

move away from quicli main!

It's no longer recommended, and creates a warning like:

warning: use of deprecated item 'failure::error::Error::causes': please use the 'iter_chain()' method instead
  --> src/main.rs:20:1
   |
20 | / main!(
21 | |     |args: Cli, log_level: verbosity| match run_floki_from_args(&args) {
22 | |         Ok(()) => (),
23 | |         Err(e) => {
...  |
27 | |     }
28 | | );
   | |__^

2018-ify code

Move code over to Rust 2018

Bug in docker-in-docker in floki 0.6.0

unknown flag: --link alongguid:floki-docker
See 'docker run --help'.
07:04:50 [ERROR] A problem occured: Running container failed: docker run exited with return code 125

Automate Cargo dependency bumping

Probably there is something we can use off-the-shelf to submit PRs with dependencies bumped.

Why? It would be good to keep everything nice and up-to-date where possible, but this is boring tedious work.

Better support for build caches

Some build tools like to persist build data to disk. It would be nice if floki allowed build caches created inside the container to persist between container launches, and even across containers in different which might want to share a cache (e.g. Rust builds).

Caches should work even if the user hasn't configured them (as in, they should do something sensible if enabled, and not rely on the users environment), but it may be worthwhile allowing users to set a particular file directory for a cache.

Invalid configuration options in `floki.yaml` are not rejected

This means it is easy to include keys which have no meaning

Travis CI warnings

Travis CI has the following warnings:

• deploy: deprecated key skip_cleanup (not supported in dpl v2, use cleanup)
• jobs.include.deploy: deprecated key skip_cleanup (not supported in dpl v2, use cleanup)
• jobs.include.deploy: missing strategy, using the default git
• root: missing dist, using the default xenial
• deploy: key api_key is an alias for token, using token
• jobs.include.deploy: key github_token is an alias for token, using token

Should be easy to fix up - the JSON at the bottom of https://travis-ci.org/github/Metaswitch/floki/jobs/708653708/config for example shows most of the resolved config.

dind is broken with latest dind images

This appears to be due to docker now expecting to find TLS certificates.

Enable dind image to be specified in configuration file

dind currently uses a hardcoded image, which has a tag which varies (dind:stable). This can harm reproducibility of environments.

As a follow on to the fix to #24, it would be better to allow users to fix a version of dind in the configuration file if they need to. This helps users deal with any follow on dind issues, without needing immediate code changes.

Better debugging of init stages

Being dropped out of floki when an init step fails is kind of annoying, but also kind of useful. This boils down to whether the inner commands are linked with ; (permissive) or '&&' (get thrown out on error).

Allow docker build stages to be used as build environment

It's a common pattern to have multi-stage Dockerfiles, an intermediate stage of which is a good candidate for an interactive build container.

It would be useful if floki allowed users to select an intermediate stage as its image.

Automate documentation build

Travis CI could build and deploy the documentation.

Currently the documentation is built with hugo and then pushed by hand. Ideally we'd build and deploy automatically on tags (and perhaps check the documentation builds as part of CI).

Inner shell and outer shell have different restrictions

In order to get user switching working appropriately when the upstream Docker image has USER , I have used the following:

shell:
  inner: sudo su -c bash
  outer: bash

Trial and error has revealed that the outer shell cannot have a freeform input, but the inner shell can.

Latest release has linux release in .zip, not .tar.gz

https://github.com/Metaswitch/floki/releases/download/0.4.1/floki-0.4.1-linux.zip exists; it should be a .tar.gz.

`floki` doesn't find `Dockerfile` when searching down directories

If your directory tree looks like

| floki.yaml
| Dockerfile
| some_folder/

and you run floki in some_folder, then floki will search down the directory tree for floki.yaml, but if configured to use the Dockerfile for the image, it will fail to find the Dockerfile.

Docker-out-of-Docker support

We've got docker-in-docker support, but support for mounting and using the host's docker would be useful too - e.g. for building Docker images for use on the host.

Assumptions that paths can always be utf-8 decoded

In general in Unix any sequence of non-null bytes is a permissible path. In various places in the source (interpret.rs contains examples in configure_volumes and get_mount_specification) floki does a panicking to_str, which may lead to crashes on legitimate (if illegible) paths.

We should audit these and either guarantee they can't cause issues, or deal with them properly. A key question here is probably how to pass these down to the underlying Command (if I recall correctly, args are specified with &str, but there may be additional methods, I haven't looked).

Rework the `interpret` module and `DockerCommandBuilder` structure

The interfaces in the interpret module are a little bizarre. Investigate and make them simpler.

Restore logging verbosity switch

Somewhere in the structopt/clap upgrade verbosity switches got (re)moved. I just removed the option for now to restore a working build, but it should be restored since it's handy for debugging/testing.

Also somehow CI didn't fail, even though the project didn't build.

Tedious.