raing3 / local-api-gateway Goto Github PK

Gateway should handle OPTIONS requests for CORS preflight.

More information: https://expressjs.com/en/resources/middleware/cors.html

Add options to allow configure host names to be resolved to specific IP addresses in all integrations.

Example:

integration_hosts:
  my_host.local: ~ # resolve my_host.local in the container to the ip address the host resolves to
  my_host2.local: 192.168.1.2 # resolve my_host2.local to a specific ip address (may be different to what the host resolves it to)

The presence of the configuration should result in the merged docker-compose.yml file containing "extra_hosts" with the mapping: https://docs.docker.com/compose/compose-file/compose-file-v3/#extra_hosts

Need to confirm compatiblity with different versions of Docker and add up-front warning if attempting to use tool with a version that is lower than what is supported.

Known to have issues with docker-compose 1.25.2:

ERROR: Version in ".../.local-api-gateway/docker-compose.yml" is unsupported. You might be seeing this error because you're using the wrong Compose file version. Either specify a supported version (e.g "2.2" or "3.3") and place your service definitions under the `services` key, or omit the `version` key and place your service definitions at the root of the file to use version 1.

For testing purposes it may be beneficial to modify files in the .local-api-gateway folder from what is compiled by the tool.

Current thoughts are to implement this as a CLI argument such as --no-build-config or similar to disable rebuilding the config files.

Things to document:

• .local-api-gateway folder is a cache folder and shouldn't need to be manually edited. done
• Need to re-up if changes are made to the config file or middleware. done
• Need to run build after updating the cli tool. done
• Contribution guidelines.

Currently the "networks" key in docker-compose.yml isn't supported: https://docs.docker.com/compose/networking/

As part of this would be good to restrict container networking boundaries to avoid the potential of integrations communicating with other integrations directly. Maybe this should be a config?

Need to make the following changes:

• Merge networking key of individual docker-compose.yml into combined docker-compose.yml.
• Prefix network names (in both the service and the network) with the integration name to avoid conflicts.
• If no "networks" key exists in the individual docker-compose.yml and there are more than 1 services defined create a network and add to all services.
• If "networks" key exists in the individual docker-compose.yml change to aliased network name.
• Add alises for service names so that they can be accessed using the same name defined in the individual docker-compose.yml.
• Create network for gateway which has access to all services that have routes defined.
• Potentially add network configuration to local-api-gateway.yml to configure accessibility of services across integrations. Not handling for now.
• Also rewrite "depends_on" to use aliased service names https://docs.docker.com/compose/compose-file/compose-file-v3/#depends_on

Command should:

• Validate structure, types, etc. of local-api-gateway.yml are valid.
• Referenced middleware files exist.
• Maybe, probably not: checkout integrations and make sure they exist, their build scripts exist, route mappings, etc.

Command would be beneficial for a CI pipeline.

There are issues when using a Dockerfile via docker-compose with a uppercase service name.

Possibly relates to: docker/compose#1416

Should look at disallowing/transforming uppercase characters.

Ideas:

• "Might be an idea to add a gitignored config file or something. So you can turn containers on/off if you want and only have a subset running easily. Instead of needing to edit the yml file."
• Potentially have dependency tree defined in config.
• Potentially CLI argument for "up" (and similar commands?) using similar syntax to Docker CLI: https://docs.docker.com/engine/reference/commandline/ps/#filtering

Currently if an error occurs in the gateway it requires re-running local-api-gateway up.

The gateway container should be changed to that it automatically restarts, either always or on-failure.