Skip to content
This repository has been archived by the owner on Apr 13, 2023. It is now read-only.

Config settings #23

Closed
awojtczyk opened this issue May 5, 2020 · 2 comments
Closed

Config settings #23

awojtczyk opened this issue May 5, 2020 · 2 comments
Labels
documentation Improvements or additions to documentation feedback welcome Feedback from the community welcome help wanted Extra attention is needed

Comments

@awojtczyk
Copy link
Contributor

What would be the best?

  • current config file to store all options
  • .env file
  • user prompts during the installation?
@woudsma
Copy link
Member

woudsma commented May 6, 2020

So currently for non-secret project variables we're using .env files, to specify the domain for example. This works fine atm, but when using secrets we should avoid this and make it clear in the documentation that storing and committing secrets defined in a .env file is bad practice and dangerous.

Usually I store my project secrets in my VCS (Github/Gitlab/Bitbucket) repository settings, and use pipelines/actions to deploy an application to a server running Dokku for example.

Using Dokku you would store secrets (or other env vars) on the server using the Dokku CLI in most cases. I kind of want to avoid that - needing to manually log in and set env vars on the server over SSH.

I'd prefer storing project secrets in their repository settings, but that would mean using a VCS-specific CI system such as Github Actions / Gitlab CI or Bitbucket Pipelines, which would build the application Docker images, store them in a registry, and letting the server know that it needs to deploy app containers from those images. In that case, it would be nice to be able to skip the build step within Swarmlet, and be able to just pull the latest image from a (private) registry after it has been built and pushed using Actions / Gitlab CI / etc..

This begs for improvement of the current internal registry configuration. It would be nice to be able to use a registry hosted on your swarm to be accessible externally by default, at registry.mydomain.com for example.

A user prompt / CLI wizard during installation is something I'm looking into, that would help setting initial environment variables such as the FQDN ("Fully Qualified Domain Name" such as manager-1.mydomain.com, dev.mydomain.com or just mydomain.com) Swarmlet will use to host it's included services.

If the user doesn't use external CI tools to build and push their applications to the swarm, but just wants to deploy apps to their own swarm and store the code locally and on Github for example, it might be nice to store the secrets on the swarm itself using a web UI hosted on the swarm. I haven't really looked into that, but I know it's possible to manually add secrets in Swarmpit, possibly in Portainer as well, and definitely in a self-hosted Gitlab CE setup. We're using Consul right now to store the certificates in a distributed way, it would be nice to be able to use that for other secrets as well if that's possible. I've also read something about Hashicorp Vault, but haven't looked into that.

@woudsma woudsma added documentation Improvements or additions to documentation feedback welcome Feedback from the community welcome help wanted Extra attention is needed labels May 6, 2020
@woudsma
Copy link
Member

woudsma commented May 6, 2020

Closing this because of #26

@woudsma woudsma closed this as completed May 6, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
documentation Improvements or additions to documentation feedback welcome Feedback from the community welcome help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants