HashiStack

[thoward27]

Add a devcontainer for working with the HashiStack (nomad + consul + vault)

There are still some problems here, when trying to walk through Nomad's vault integration guide I get the following error:

$ vault operator init -key-shares=1 -key-threshold=1
Error initializing: Put https://127.0.0.1:8200/v1/sys/init: dial tcp 127.0.0.1:8200: connect: connection refused

References:

• Vagrant file with everything working
• Docker consul
• Docker vault

[msftclas]

All CLA requirements met.

[Chuxel]

Cool stuff!

Most likely what is going on is Vault is not actually running. Note this part of the Vault dockerfile:

# The entry point script uses dumb-init as the top-level process to reap any
# zombie processes created by Vault sub-processes.
#
# For production derivatives of this container, you shoud add the IPC_LOCK
# capability so that Vault can mlock memory.
COPY docker-entrypoint.sh /usr/local/bin/docker-entrypoint.sh
ENTRYPOINT ["docker-entrypoint.sh"]

# By default you'll get a single-node development server that stores everything
# in RAM and bootstraps itself. Don't use this configuration for production.
CMD ["server", "-dev"]

You'll also need to set a devcontainer.json property for the entrypoint and command to kick in:

"overrideCommand": false

[thoward27]

Okay, so now I can add keys to vault, see all the UIs, everything seems great, but then I get task_dir: mount: operation not permitted when trying to run any nomad job.

https://github.com/hashicorp/nomad/issues/4199

That seems to have some indications of what changes need to be made, but alas I am entering unknown territory..

Think I need to use:

https://docs.docker.com/storage/tmpfs/

[thoward27]

As far as I can tell, this now works with nomad / consul / vault locally, all using development servers. I was able to deploy a redis job to nomad, add keys to vault, and view the consul UI.

Things I think could be done better:

• up.sh: How should this be called? Should it be a Docker entrypoint?
• appPorts: I cannot for the life of me figure out how to get ports 4646, 8500, and 8200 to play nicely with this setup.

[Chuxel]

@thoward27 On appPorts, what might be going on is that the servers are only listening to localhost - which won't work with "published" Docker ports. (This is sort of like you starting a server on your local machine, and then trying to connect to it from another one.)

The current VS Code Insiders release as a "forwardPorts" directive that uses VS Code's built in forwarding mechanism instead of a Docker "publish". That might work in this case and will land in stable sometime next week assuming all goes as expected.

In terms of "up.sh", using cmd/entrypoint is the way to go.

One other thing I noticed is you can likely depend on the newly published base ubuntu image we're also now publishing. mcr.microsoft.com/vscode/devcontainers/base:ubuntu-18.04 It replaces and expands the ubuntu-18.04 definition to include zsh, oh my zsh, along with git, a non-root user and common dependencies. (Everything in this script). The images we currently publish are listed here.

[bamurtaugh]

Thanks again for opening this PR and for the discussion so far!

As a heads up, our team has been actively focused on an updated plan for community contributions and this repo moving forward, which we've now outlined in this issue: https://github.com/microsoft/vscode-dev-containers/issues/1589. This includes moving to a couple new repos for images (https://github.com/devcontainers/images) and Features (https://github.com/devcontainers/features).

We anticipate to have a similar repo and distribution process for templates/definitions. We'll keep everyone updated (likely via another issue in this repo or comment on https://github.com/microsoft/vscode-dev-containers/issues/1589) when our new templates repo is available and the process is defined.

Please let me know if you have any questions, thank you!