wish / dev Goto Github PK

If you use an image that is built on top of another one it would be nice to be able to build it as part of the dependency checking step.

One way to do it:

i.e.,
projects:
foo:
docker_compose_files: [ "docker-compose.yaml"]
depends_on: ["bar"]

builds:
bar:
docker_file: ["Dockerfile.bar"]

dev foo up would then run docker build -f Dockfile.bar before attemping to bring up foo.

One other way might be to forgo 'builds' altogether and focus and instead focus on commands.

i.e.,

commands:
bar:
cmd: 'docker build -f Dockerfile.bar'

Both of these suggestions need flushing out..

To help document how the project can be configured.

Make it part of a test so there's some coverage there

When you run dev and it finds no projects it shows a one-liner about the program. Typically this would show all the commands and command flags, but since there are no commands at this point, the output is sparse. Would be nice to say that no projects were found and either to move to a directory containing docker-compose.yml files, setup a link from ~/.dev.yaml to a project config, etc.

docker-compose adds a prefix to all containers it creates. By default this prefix is the directory name of the first docker-compose file specified with -f flag (need to verify). This can be overriden with the -p flag or with the environment variable COMPOSE_PROJECT_NAME. Unfortunately it cannot be the empty string so some support has to be added to dev to get the tool to work at all, but it would be nice if projects could specify the prefix. Will have to be careful how this will work when multiple compose files are used (as is likely with this tool).

dev {project} down attempts to remove all non-shared dependencies via docker-compose.. This fails when the containers use an external network. Use docker api to make it happen. Start with just shutting down the project container, but should parse the non shared config and shut it all down.

This happens most often after a reboot. The network doesn't exist so dev creates it, but the containers still have the old network id so they fail to come up.

PPA over on launchpad, brew via public github repo

Configuration file currently assumes full paths, though it does do some environment variable handling (poorly I might add). Allow the use of relative paths.

Makes sense to match the configuration of docker-compose projects which users of this project must know ahead of time.

If the user is in a sub-directory of the project, commands run with 'dev sh' should be relative to that directory. Be nice to be able to do it without the need to configure it.

dev attempts to map the commands entered to their locations on the container. This is done by assuming that .dev.yaml is the root of the volume you have mapped in. This breaks down when you specify multiple config files. With multiple config files, the location of the first .dev.yaml is used even though the sh command could be running for a project in a subsquent dev yaml.

Currently searching is performed only for docker-compose.yml files, be nice to support them both as they are both supported by docker-compose.

See: https://github.com/docker/cli/blob/master/cli/compose/loader/loader.go

For supporting other docker-compose versions other than 3.6

Build on commit in all branches

If you have projects in different repositories you may want to use this tool to coordinate their usage together. While this is possible with one configuration file, it would lead to things being defined in the wrong place or duplicated.

How about $DEV_CONFIG="/Project/foo/.dev.yaml,"/Project/bar/.dev.yaml"

dev would merge all the configs into one. dependencies in foo/.dev.yaml should be able to depend on aspects of bar/.dev.yaml and vice versa.

Nice to have

Some docker-compose configs will pull down images from repositories where it will be necessary to login first in order to fetch them.

It's possible to specify an "external" network with docker-compose. Compose will then assume the network exists and provided that it does exist, allow you to use it like you would any other network. Some projects may want to share an "external" network. If dev could create these networks itself and ensure they exist before bringing the containers up, it would really simplify things.

Projects should be able to say they "depend" on a specific network and it will be created/modified as dictated in the configuration.

When dev {project} down is run only the project container is shut down. Any other containers listed in the docker-compose files for the project are not brought down. This was intentional b/c dev doesn't really know the relationship between all the projects. Once issue #4 is resolved, flags can be added to the 'down' command to shut down all shared dependencies (probably should result in a warning that other dependent projects will also be shu down).

Especially if you're using more than one docker file, it would be nice to have an easy way to build a particular container instead of rebuilding them all.

i.e., Say project foo relies on container nginx which i'd like to modify. It would be nice to do this:

dev foo build nginx

What i do now is run DEV_CONFIG=debug dev build foo and then ctl-c as soon as I see the build start and take a look at the logs to see the exact docker-compose invocation. Then I copy that and add 'nginx' at the end of it. After building i just run dev foo up to get all the containers to restart. It's not horrible, but could be made easier by adding all the container dependencies as sub-commands.

Projects should be able to define a list of dependencies. These dependencies could be on a container registry (#2) an external network (#3) or another docker-compose project.

Registries would only be needed at 'up' time, so login should only happen then, but other dependencies may have different requirements.

For example, it might be nice to have a 'dev python' command which runs 'dev sh python foo.py'. Adding code for each of these cases shouldn't be necessary. Add the ability to define these shortcuts globally or per-project in the configuration file.

I'm thinking that a command defined outside of the project would apply to all projects, i.e., in the case above, dev projectname python.

Possible configuration (needs work)

sh_shortcuts: {
   "python": "/home/app/.virtualenv/bin/python",
}

Be nice to support .?dev.{yml|yaml}

If a user performs dev {project} sh command and the project container is not up, bring it up automatically