Docker entrypoints under control

RKD has enough small footprint so that it can be used as an entrypoint in docker containers. There are a few features that are making RKD very attractive to use in this role.

Environment variables

Defined commandline --my-switch can have optionally overridden value with environment variable. In docker it can help easily adjusting default values.

Task needs to create an explicit declaration of environment variable:

def get_declared_envs(self) -> Dict[str, ArgumentEnv]:
    return {
        'MY_SWITCH': ArgumentEnv(name='MY_SWITCH', switch='--switch-name', default=''),
    }

def execute(self, ctx: ExecutionContext) -> bool:
    # this one will look for a switch value, if switch has default value, then it will look for an environment variable
    ctx.get_arg_or_env('--my-switch')

Arguments propagation

When setting ENTRYPOINT ["rkd", ":entrypoint"] everything that will be passed as docker’s CMD will be passed to rkd, so additional tasks and arguments can be appended.

Tasks customization

It is a good practice to split your entrypoint into multiple tasks executed one-by-one. This gives you a possibility to create new makefile.yaml/py in any place and modify RKD_PATH environment variable to add additional tasks or replace existing. The RKD_PATH has always higher priority than current .rkd directory.

Possible options:

  • Create a bind-mount volume with additional .rkd/makefile.yaml, add .rkd/makefile.yaml into container and set RKD_PATH to point to .rkd directory
  • Create new docker image having original in FROM, add .rkd/makefile.yaml into container and set RKD_PATH to point to .rkd directory

Massive files rendering with JINJA2

:j2:directory-to-directory is a specially designed task to render JINJA2 templates recursively preserving a directory structure. You can create for example templates/etc/nginx/nginx.conf.j2 and render ./templates/etc into /etc with all files being copied on the fly.

All jinja2 templates will have access to environment variables - with templating syntax you can define very advanced configuration files

Privileges dropping

Often in entrypoint there are cache/uploads permissions corrected, so the root user is used. To migrate the application, to run the webserver the privileges could be dropped.

Solutions:

  • In YAML syntax each task have a possible field to use: become: user-name-here
  • In Python class TaskInterface has method get_become_as() that should return empty string or a username to use sudo with
  • In commandline there is a switch --become=user-name-here that can be used with most of the tasks