get-bridge / muss Goto Github PK

Like docker cp to simplify getting files into/out of containers?

to help people debug.
This would probably involve shelling out to lsof and/or ps and might be different for mac vs linux.
If you have another process using *:port docker will fail instantly when it can't bind to the port.
However, if you have a process using 127.0.0.1:port docker will work and then when you try to connect to lvh.me it will use the process specifically sitting on 127.0.0.1:port (it will go to docker only if there is no conflict).
This situation is much more confusing than "docker won't start".

see also docker/compose#1294

before executing any subcommand print out the command
(and maybe a description if attached)
to remove some of the mystery of what it's doing.

We could define common commands in module definitions.

Then you could do muss console psql (or muss console db or whatever you want to call it)
instead of muss run postgres psql or psql -h $dockerhost -p $exposedport -U $whatuserisit

If we used this instead of using psql directly then you wouldn't need to expose global ports and could avoid port conflicts that come from running too many projects.

For secret_commands we could define a command in the config that would allow for disabling the fetching of the secret.

As an example, it could simplify entrypoints if we could tell muss not to set a secret that is already configured in .env*.local instead of getting the secret under a different name and making the entrypoint have to decide whether or not to set it.

vault:
    # unless? override? local override?
    # unless would just not set it... override would set it?
    # maybe both?
   unless: [sh, -c, 'grep -E "^$1=" ${2:-.env*.local}', --]

instead of having to add stuff to a README
it would be nice to add "help only" subcommands that have all that info
(like module_file definitions, available configuration options, etc)
and just put those commands in the README so that people can use muss to discover project options.

With a rails app you might want to put binding.pry in a controller and then muss attach web
but that's useless if you are using passenger since passenger doesn't pass the pty...
so while you can document that in a README, it could be useful to configure in the project that muss attach web should warn if "puma isn't configured".

do_commands:
  docs: muss run something-to-generate docs
  pg_dump: muss run postgres env PGDATABASE=cluster3 pg_dump -h postgres -U postgres > tmp/muss.dumpall.sql
  pg_restore: muss exec postgres psql -h localhost -U get_smart -d postgres -f - < tmp/muss.dumpall.sql

Not sure about the command syntax though... do we put muss run in front of everything for maximum flexibility? or assume that commands would be run in a given container?
Then the do commands would be discoverable through muss help.

Simply runs status.exec once, then add options for --wait (to wait until it exits zero) and maybe a --forever option to work just like it does in up.

we could define in module definitions some commands to reset things, .e.g.

reset:
  testdb: "muss run test bash -c 'dropdb testdbname && createdb testdbname && bin/rake db:extensions db:structure:load RAILS_ENV=test'"

so that muss reset testdb would get people on their way faster and easier than down, drop a docker volume, up or other incantations.
other useful things could be caches, dev db, dynamodb-local, runtime dependencies, etc