35
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 25 Feb 2024
35 points (100.0% liked)
Free and Open Source Software
17949 readers
62 users here now
If it's free and open source and it's also software, it can be discussed here. Subcommunity of Technology.
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
Ideas what you can do. These are all SHOULD and not MUST requirements, so pick and choose what you can reasonably do in a realistic timeframe without overburdening yourself. Some of these steps can be outsourced to your community.
You can try to make a twelve factor app but some of their advice is probably not suited for your application. You will end with some 7.5factor app which is fine.
Follow SemVer and provide detailed instructions for upgrading major versions.
Use a build system which is easily installable and a language where you don't have to upgrade dependencies every second for security issues (looking at you, npm/nodejs).
Don't include a webserver which does HTTPS, let the people run their own reverse proxy.
Test your setup with and provide multiple web server configs for nginx, Apache2, Caddy, Traefik.
Test your setup with and provide multiple default configs for bare metal (with a dependency manager), Docker, Podman, Kubernetes, Kata Containers.
If you need a DB, include the possibility to migrate from a self contained one instance SQLite to a multi container pgsql/MySQL setup.
Write database migrations in both directions so people can downgrade on failures.
Make it possible to configure your system via ENV variables, ENV files and config files. Provide instructions on best practices and sane defaults. Explain these defaults and make clear configuration is optional.
Make it possible to disable authentication to add Authelia or LDAP through the webserver. Make clear that this is only to be used for external authentication.
Make it possible to run multiple parallel instances of your software without affecting the database consistency, e.g. for high availability or horizontal scaling.
Provide a versioned, documented API (does not need to be public) and use it yourself for your frontend. Provide a telemetry endpoint which is human readable and machine readable, so Prometheus or a similar system can scrape it.
Great resource!
Good point. Personally, I take backups before upgrades and restore if anything goes wrong. But, I understand how downgrading sometimes is just easier.
I have trouble coming up with a migration procedure that makes sense to me. I have the following in mind:
I am bit worried about this one, environment variables can be a security concern. Specifically, I am not sure if I should allow providing secrets (like db connection strings) through environment variables. I am inclined to let people do what they want to, but issue a warning.
I am considering adding support for oauth through keycloak. My assumption is that if you are going to host your own LDAP, you can probably configure keycloak too. Do you think that makes sense?
Ideally, an instance shouldn't be big enough to need it. I know, famous last words, but in my case I think it's a bad problem to have. I am going out of scope, but I am wondering where is the line between discouraging large scale deployments and designing something pre-destined to obscurity.
Not even on my radar, thanks for bringing it into my attention ๐
Why require keycloak specifically? Maybe I want to use another authentication gateway.