Que peut-on trouver derrière les mots «la plus grande école en ligne d'Europe»? D'une part, cela représente 1 000 leçons par heure, 10 000 enseignants, 100 000 étudiants. Et pour moi, ingénieur en infrastructure, cela comprend également plus de 200 serveurs, des centaines de services (micro et non), des noms de domaine du 2ème au 6ème niveau. Partout où vous avez besoin de SSL et, par conséquent, d'un certificat pour cela.
Pour la plupart, nous utilisons des certificats Let's Encrypt. Leurs avantages sont qu'ils sont gratuits et que la réception est entièrement automatisée. En revanche, ils ont une particularité: courte - seulement trois mois - validité. En conséquence, ils doivent être mis à jour fréquemment. Nous avons essayé de l'automatiser d'une manière ou d'une autre, mais il y avait toujours beaucoup de travail manuel et quelque chose se cassait constamment. Il y a un an, nous avons trouvé une méthode simple et fiable pour mettre à jour cette pile de certificats et depuis, nous avons oublié ce problème.D'un certificat sur un serveur à des centaines dans plusieurs centres de données
Il était une fois un seul serveur. Et sur elle vivait un certbot, qui travaillait sous la couronne. Puis un serveur a cessé de faire face à la charge, donc un autre serveur est apparu. Et puis de plus en plus. Chacun d'eux avait ses propres certificats avec son propre ensemble unique de noms, et partout où il était nécessaire de configurer leur mise à jour. Quelque part pendant l'extension, ils ont copié les certificats existants, mais ont oublié la mise à jour.Afin d'obtenir un certificat Let's Encrypt, vous devez confirmer la propriété du nom de domaine spécifié dans le certificat. Cela se fait généralement avec une requête HTTP inverse.Voici quelques difficultés standard que nous avons rencontrées au cours de notre croissance:- : . .
- HTTP. , . . - LDAP. - . .
Dans certains endroits, les certificats auto-signés sont utilisés depuis un certain temps, et cela semblait être une bonne solution dans les endroits où l'authentification n'est pas nécessaire - par exemple, pour les tests internes. Pour empêcher le navigateur de signaler constamment un «site suspect», il vous suffit d'ajouter notre certificat racine à la liste des sites de confiance, et le point est dans le chapeau. Mais des difficultés ultérieures sont apparues ici aussi.
Le problème est que dans BrowserStack, que les testeurs utilisent, il est impossible d'ajouter un certificat à la liste de confiance pour au moins iPad, Mac, iPhone. Les testeurs ont donc dû faire face à des avertissements pop-up constamment sur les sites dangereux.Rechercher une solution
Bien sûr, tout d'abord, vous devez effectuer une surveillance afin de découvrir les certificats qui se terminent non pas lorsqu'ils sont déjà terminés, mais un peu plus tôt. Tant pis. La surveillance est, nous savons maintenant que les certificats se termineront bientôt ici et là. Et maintenant, que puis-je faire?
Big Ear est un vieux bot qui ne ruinera pas un certificat.Et utilisons des certificats génériques? Allons! Let's Encrypt les émet déjà. Certes, vous devrez configurer la confirmation de la propriété du domaine via DNS. Et notre DNS vit dans AWS Route53. Et vous devez décomposer les détails d'accès dans AWS sur tous les serveurs. Et avec l'arrivée de nouveaux serveurs, copiez là aussi toute cette économie.Eh bien, les noms de troisième niveau sont couverts par des caractères génériques. Et que faire des noms de 4e niveau et plus? Nous avons de nombreuses équipes engagées dans le développement de différents services. Maintenant, il est habituel de diviser le frontend et le backend. Et si le frontend obtient un nom de troisième niveau comme service.skyeng.ru , le backend essaie de donner le nom api.service.skyeng.ru . Hmm, peut-être leur ont-ils interdit de continuer à faire ça? Bonne idée! Et que faire des dizaines de celles existantes? Serait-ce d'une main de fer de les regrouper en un seul nom de domaine? Remplacez tous ces noms de différents niveaux par des URL comme skyeng.ru/service. Techniquement, c'est une option, mais combien de temps cela prend-il? Et comment les entreprises peuvent-elles justifier la nécessité de telles actions? Nous avons plus de 30 équipes de développement, persuadons tout le monde - cela prendra au moins six mois. Et nous créons un point de défaillance unique. Qu'on le veuille ou non, c'est une décision controversée.Quelles autres idées y a-t-il? .. Peut - être qu'un certificat peut être fait où nous incluons tout-tout-tout? Et nous allons l'installer sur tous les serveurs. Cela pourrait être la solution à nos problèmes, mais Let's Encrypt vous permet d'avoir seulement 100 noms dans le certificat, et nous avons déjà plus d'un microservice.Que faire avec les testeurs? Ils n’ont rien trouvé, mais ils se plaignent constamment. Toutes conneries sauf les abeilles. Les abeilles sont aussi des ordures, mais il y en a beaucoup. Chaque développeur ou testeur reçoit un serveur de test - nous les appelons testing. Les tests ne sont pas des abeilles, mais il y en a déjà plus d'une centaine. Et pour chacun, tous les projets sont déployés. C'est tout. Et si pour la vente, vous avez besoin de N certificats, il y a le même montant pour chaque test. Jusqu'à présent, ils sont auto-signés. Ce serait formidable de les remplacer par de vrais ...Deux livres de lecture et une source de vérité
Le cygne, le cancer et le brochet n'apporteront le chariot nulle part. Nous avons besoin d'un centre de contrôle à serveur unique . Dans notre cas, c'est Ansible. Certbot sur chaque serveur est mauvais. Laissez tous les certificats être stockés en un seul endroit. Si quelque part quelqu'un a besoin d'un certificat, venez à cet endroit et prenez la dernière version sur l'étagère. Et nous nous assurerons que les certificats sont toujours à jour dans ce magasin.Les détails d'accès AWS sont également présents en un seul endroit. En conséquence, les questions disparaissent, telles que la configuration de l'AWS CLI sur un nouveau serveur, qui a accès à Route53 et autres.Tous les certificats requis sont décrits dans un fichier au format Ansible au format YAML: certificates:
- common_name: skyeng.ru
alt_names:
- *.skyeng.ru
- common_name: olympiad.skyeng.ru
alt_names:
- *.olympiad.skyeng.ru
- api.content.olympiad.skyeng.ru
- games.skyeng.ru
- common_name: skyeng.tech
alt_names:
- *.skyeng.tech
. . .
Un playbook est lancé périodiquement, qui passe par cette liste et fait son travail acharné - essentiellement la même chose que certbot:- crée un compte avec Let's Encrypt Certificate Authority
- génère une clé privée
- génère un certificat (pas encore signé) - la soi-disant demande de signature de certificat
- envoie une demande de signature
- reçoit un défi DNS
- place les enregistrements reçus dans DNS
- envoie à nouveau une demande de signature
- et, ayant finalement reçu le certificat signé, le met dans le magasin.
Playbook est effectué une fois par jour. S'il ne pouvait pas renouveler de certificats pour une raison quelconque - que ce soit des problèmes de réseau ou des erreurs du côté de Let's Encrypt - ce n'est pas un problème. Sera mis à jour la prochaine fois.Maintenant, lorsque SSL est nécessaire sur un hôte de service, vous pouvez accéder à ce référentiel et obtenir quelques fichiers à partir de là - l'opération la plus simple effectuée par le deuxième playbook ... Les certificats nécessaires sur cet hôte sont décrits dans les paramètres de cet hôte, dans les inventaires / host_vars / server .yml : certificates:
- common_name: skyeng.ru
handler: reload nginx
- common_name: crm.skyeng.ru
. . .
Si les fichiers ont changé, Ansible tire un crochet - il est typique de redémarrer Nginx (dans notre cas, c'est l'action par défaut). Et de la même manière, vous pouvez obtenir des certificats d'autres autorités de certification qui utilisent le protocole ACME.Total
- Nous avions de nombreuses configurations différentes. Quelque chose s'est constamment cassé. Souvent, je devais grimper sur les serveurs et comprendre ce qui était tombé à nouveau.
- Nous avons maintenant deux playbooks et tout est enregistré au même endroit. Tout fonctionne comme une horloge. La vie est devenue plus ennuyeuse.
Essai
Oui, qu'en est-il des testeurs avec leurs tests? Chaque développeur ou testeur reçoit un serveur de test personnel - testing. Il y en a actuellement environ 200. Ils ont des noms sous la forme test-y123.skyeng.link , où 123 est le numéro du test. La création et la suppression des tests sont automatisées. L'un des composants de l'action est l'installation d'un certificat SSL dessus. Un certificat SSL est généré à l'avance, avec des noms par modèle: ssl_cert_pattern:
- *
- *.auth
- *.bill
. . .
Seulement environ 30 noms. Donc, le certificat est livré avec des noms test-y123.skyeng.link
*.test-y123.skyeng.link
*.auth.test-y123.skyeng.link
*.bill.test-y123.skyeng.link
etc.Après le licenciement du développeur ou du testeur, ses tests sont supprimés. Le certificat reste prêt à l'emploi. C'est tout ce qui est stocké. Vous savez vous-même où il est décomposé en hôtes, vous savez comment.PS
Référentiel avec code .Il pourrait également être intéressant de lire sur ce sujet comment Stack Overflow est passé au HTTPS :- Des centaines de domaines de différents niveaux
- Websockets
- Beaucoup d'API HTTP (problèmes de proxy)
- Tout faire et ne pas baisser les performances
Si vous avez des questions, écrivez dans les commentaires, je me ferai un plaisir d'y répondre.