moneyhub / navy Goto Github PK

getLANIP always returns 127.0.1.1 for me, and at least one other linux user.

It seems to work for some OSX users, but for some it returns something else, e.g. a virtualbox IP.

Would something like this be better:

const interfaceName = "wlan0" // supplied by user

const interfaces = os.networkInterfaces();
const networkInterface = interfaces[interfaceName]
for (const i in networkInterface) {
  var address = networkInterface[i];
  if (address.family === 'IPv4') {
    console.log(address.address);
  }
}

It does require the user to input which interfaceName to use though.

This error message appears when running any navy command when a lot of services are running.

At the moment running commands like navy launch just results in a long wait and no feedback is given.
This is especially noticeable when Docker starts downloading images and there's no progress bar.

Sometimes (like for testing) it's useful to clone a service and maybe launch it with a custom tag so you can compare versions.

Sometimes it's a bit cumbersome setting the NAVY_EXTERNAL_IP environment variable. There should be a way to set this on the command line which is persisted in config.

Maybe a generic navy config command just like npm config?

Also we could have navy allow-external-access which automates setting your external IP to your LAN ip address and prints out some usage examples on the terminal.

When orphans exist (services which did exist in config but have been removed which are still launched) launch and relaunch should crash out. This can be overridden with a --force flag, but the idea is that the user should run a cleanup command to remove orphans.

Can be useful at the start of a test run where you want to put a service into development before running some tests. In this case you will not want to keep the logs in the foreground.

A way of doing this might be:

$ navy develop --no-logs

When running navy launch without any services as command line arguments,
a prompt should be presented where the user can select what services they'd like to bring up.

Dynamic config is useful for changing environment variables and other configuration in response to dynamic variables (e.g service URL).

This is useful for frontend services which might need to pass in the user facing URL for the server as an environment variable, or maybe a backend service which needs the URL to a frontend service for CORS configuration.

Docker compose configuration should be able to be packaged up in an NPM package.

This will be much faster than relying on docker-compose.

This will streamline the getting started process

Should pull and relaunch services.

I don't think file packages/navy/src/drivers/docker-compose/index.js line 127 is correct.

If service A depends_on service B in your compose file (i.e. a app service depends_on db service) and you then run navy develop on service A, the dependency will be ignored. I haven't looked into why yet.

@madjam002 was this the intended behaviour?

This can be specified in Navyfile.js

Finish first version of the website and improve documentation

@madjam002 can you include the same collaborators on the navy-plugin-nodejs npm repo as we have on navy please?

Cheers

The CLI has gotten a bit slow 👎

Sometimes useful for test runs, e.g for determining the IP and port of a database service to connect to for a integration test run.

Say you have a lot of repos for your microservices and you're using the same navy configuration across these microservices.

When running navy commands, you might want the navy name to be "myapplication" for example, and this could be defined in a .navyrc file.

When running navy, it will look for a .navyrc file in the current directory. If not found, it will work its way up the directory tree.

It should be able to install plugins for a Navy.
Plugins can extend the CLI to add new commands and extend others.
Plugins come in the form of NPM packages, and a plugin can be a composition of multiple other plugins.

Installed plugins will be tracked in the state JSON file for the navy, and the node modules folder should be in the directory for the navy.

The plugin API is undecided at this point.

This is dependent on the HEALTHCHECK option in Docker 1.12.

At the moment it's not obvious why you need to run navy launch after navy refresh-config for example.

It tries to find the package in the directory @my/package@tag it's actually stored in @my/package

The docs in the repo are not mirrored on the public website. Specifically, the switch from xip to nip doesn't show up.

Should proxy through to docker compose.

From my understanding, a URL is registered in the nginx proxy for each service running, something like http://myservicename.dev.127.0.0.1.xip.io.

When getUrlForService is invoked, it returns something of the same form.

The problem arises when we change, for example, xip for nip. nginx can have services registered with xip URLs, and getUrlForService will return nip URLs which won't work.

As I see it there are two possible solutions here:

1. Make nginx match only on the <servicename>.<navyname> part of the url
2. Make getUrlForService look up the url it has registered with nginx for a given service, and return that, rather than assume it's used xip or nip.

If a docker-compose file specifies an image and a dockerfile to build, the dockerfile should be built and used when using develop mode. The image should be used when not in develop mode.

Maybe a command as well:

$ navy rebuild [?service]

to rebuild the images for the service.

Maybe also it should be possible to specify build parameters such as context path and dockerfile path in .navyrc, as sometimes your docker-compose won't be in the same directory as your service.

Used for overriding the tag of an image for a service. Will pull the image with the tag and relaunch the service. There should also be a reset-tag command to reset the tag back to whatever it is in the compose configuration.

Should also show the tag being used in status and ps.

navy services?

navy import - Imports docker compose configuration from current directory and initialises navy
navy launch - Launches services (like it does now)
navy down - Brings down services (equivilent of navy destroy now)
navy destroy - Deletes navy but keeps services in docker compose if there are any left. Should throw an error if there are services that still exist though, this can be overridden with --force.

There doesn't seem to be a full list of the currently emitted lifecycle hooks in the docs, I may be wrong?

This will be useful for accessing launched services without having to worry about ports. It also means that multiple instances of the same environment can be launched in parallel without conflicting ports, because ports don't need to be published and the service instead can be accessed from behind a URL.

For now we can use xip.io for DNS.