What are the best practice for domain names (dev, staging, production)?
SslKubernetesCloudflarePaasDeisSsl Problem Overview
With the rise of containers, Kuberenetes, 12 Factor etc, it has become easier to replicate an identical environment across dev, staging and production. However, what there appears to be no common standard to domain name conventions.
As far as I can see it, there are two ways of doing it:
- Use subdomains:
*.dev.foobar.tld*.staging.foobar.tld*.foobar.tld- Use separate domains:
*.foobar-dev.tld*.foobar-staging.tld*.foobar.tld
I can see up and downs with both approaches, but I'm curious what the common practise is.
As a side-note, Cloudflare will not issue you certificates for sub-sub domains (e.g. *.stage.foobar.tld).
Ssl Solutions
Solution 1 - Ssl
> There are only two hard things in Computer Science: cache invalidation > and naming things. > > -- Phil Karlton
Depends on the company size.
Small businesses usually go for dashes and get the wildcard certificate.
So they would have dev.example.com, test.example.com
In larger enterprises they usually have a DNS infrastructure rolled out and the provisioning processes takes care of the assignment. It usually looks like
aws-eu-central-1.appName.staging.[teamName].example.com
They would either use their own self-signed certs with the CA on all servers or have the money for the SANs.
For more inspiration:
https://blog.serverdensity.com/server-naming-conventions-and-best-practices/
Solution 2 - Ssl
A quick note about the top level domain, many companies also use the ".local" suffix for internal name resolution.
Solution 3 - Ssl
we use below dns names in our environment
- *.dev.internal.com ( development )
- *.tst.internal.com ( test )
- *.stg.internel.com ( staging )
- *.internel.com ( prod ). you can also use like *.prd.internal.com
Solution 4 - Ssl
It also depends if you want dev/test/staging be available externally, if not you can set in such way: app_name.example.dev, app_name.example.test and etc