133 karma · joined September 10, 2013
Due to the cache and read dependend nature of the database queries the latency impact is worth it.
The DNS records for the internal records are done using the kubernetes middleware (basically serving the service records). The external records are pulled in from a git repository hosting our zones as bind files. If need be zones are split into subzones per team/project. Same permission system as our code via MRs using Gitlab.
Our recommendation is build on open standards (BIND, AXFR) and use services on top of these.
I agree that using an external mail provider is usually a good idea. It mostly is your fallback communication channel and is usually easy to switch (doing replication to an offsite mail storage needs to be done to make switching easy/possible/fast). MX records \o/
Joking aside. Most likely to get a foot in the door on competition and on git related features written in Go, which might supplement or replace parts of the infrastructure within Gitlab. They already use Go for the CI runner part and as a smart, Gitlab aware proxy.
As an example:
header / Cache-Control "no-cache, max-age=86400"
header /images/ Cache-Control "max-age=86400"
header /css/ Cache-Control "max-age=604800"
header /fonts/ Cache-Control "max-age=604800"
header /icons/ Cache-Control "max-age=604800"
If you want to add the header only to static assets that can be done, but is a bit harder.Let's hope this brings the transparency, openness and community awareness owncloud/nextcloud always needed.
Let's hope this brings the transparency, openness and community awareness owncloud/nextcloud always needed.
If something like this is implemented, providing frequently used resources via a plugin, privacy aware CDN or even a custom CDN similar to https://addons.mozilla.org/en-US/firefox/addon/decentraleyes... would be possible.