Quelles sont les meilleures pratiques pour les noms de domaine (dev, la mise en scène, production)?

Avec l'augmentation de conteneurs, Kuberenetes, 12 Facteur etc, il est devenu plus facile à reproduire à l'identique l'environnement sur l'ensemble de dev, la mise en scène et la production. Cependant, ce qu'il semble y avoir aucune norme commune pour le nom de domaine conventions.

Aussi loin que je peux voir, il y a deux façons de le faire:

  • Utiliser des sous-domaines:
    • *.dev.foobar.tld
    • *.staging.foobar.tld
    • *.foobar.tld
  • Utilisation des domaines distincts:
    • *.foobar-dev.tld
    • *.foobar-staging.tld
    • *.foobar.tld

Je peux voir en haut et des bas avec les deux approches, mais je suis curieux de ce que la commune de la praxis.

Comme une note, Cloudflare ne sera pas vous délivrer des certificats pour les sous-sous-domaines (par exemple,*.stage.foobar.tld).

  • Vous pouvez également utiliser .test de domaine (en plus de example.com). Il est réservé pour la fin. *.loc, *.dev et *.tld (et amis) ne sont pas réservés et ne peuvent pas être détourné par le développeur.
InformationsquelleAutor vpetersson | 2016-09-05
  1. 22

    Il y a seulement deux choses dures dans l'Informatique: l'invalidation du cache
    et de nommer les choses.

    -- Phil Karlton

    Dépend de la taille de l'entreprise.

    Les petites entreprises vont habituellement pour les tirets et obtenir le certificat wildcard.
    Ils auraient donc dev.example.com, test.example.com

    Dans de grandes entreprises, ils ont généralement une infrastructure DNS de déploiement et le processus de déploiement prend soin de la cession. Il ressemble généralement à

    aws-eu-central-1.appName.staging.[teamName].example.com

    Ils ne pourraient utiliser leur propre auto-signé certs avec le CA sur tous les serveurs ou avoir de l'argent pour les SANs.

    Pour plus d'inspiration:

    https://blog.serverdensity.com/server-naming-conventions-and-best-practices/

    https://mnx.io/blog/a-proper-server-naming-scheme/

    https://namingschemes.com/

    • La citation viens de faire ma journée!
    • Dans un monde avec letsencrypt.org il est assez facile de simplement attribuer certs. Si vous êtes une web app, vous voulez penser à long et dur sur cookie visibilité et d'essais. Aussi loin que je peux voir, l'obtention à l'aise avec les DNS interne est une mauvaise idée, car cela fait SAAS outils de test beaucoup plus difficile à exploiter.
    InformationsquelleAutor Marcus Maxwell
  2. 1

    Il dépend aussi si vous voulez dev/test/mise en scène sera disponible à l'extérieur, si ce n'est que vous pouvez définir dans une telle manière:
    app_name.exemple.dev, app_name.exemple.test et etc

    • Et puis vous avez juste à vous assurer que votre hosts fichier est mis à jour en local sur votre machine?
    • Oui.
    • Vous pouvez utiliser .test de domaine (en plus de example.com). Il est réservé pour la fin. *.loc, *.dev et *.tld (et amis) ne sont pas réservés et ne peuvent pas être détourné par le développeur.
    InformationsquelleAutor Rimas Mocevicius
  3. 0

    Une note rapide sur le domaine de premier niveau, de nombreuses entreprises utilisent également la ".locaux" suffixe pour la résolution de noms interne.

    InformationsquelleAutor Pixel
  4. 0

    nous utilisons ci-dessous les noms dns dans notre environnement

    1. *.dev.internal.com ( développement )
    2. *.tst.internal.com ( test )
    3. *.stg.internel.com ( mise en scène )
    4. *.internel.com ( la prod ). vous pouvez également l'utiliser comme *.prd.internal.com
    InformationsquelleAutor P Ekambaram