Comment configurer les configurations réseau pour les tâches Fargate sur AWS
Permettez-moi de vous expliquer chacun des trois aspects de cette mise en œuvre: le couches de sécurité, les trois points de terminaison d’interface, et le point de terminaison de la passerelle.
Couches de sécurité
le VPC nécessite deux éléments de configuration pour fonctionner dans cette configuration:
- le Bloc CIDR décrit l’espace d’adressage dans votre VPC. Il s’agit d’une combinaison d’adresses IP et du nombre de masques de sous-réseau dont vous avez besoin. Plus le chiffre derrière la barre oblique est petit, plus les masques de sous-réseau sont disponibles.
- Nous devons également activer Noms d’hôte DNS et Prise en charge DNS. Ceux-ci prennent en charge ultérieurement l’utilisation des fonctionnalités DNS privées par les terminaux.
Voici à quoi ressemble le VPC dans un script CloudFormation:
Le connexe sous-réseau a deux éléments de configuration:
- Il définit un Bloc CIDR qui se trouve dans celui fourni par le VPC. Dans notre cas, le sous-réseau utilise tout l’espace d’adressage du VPC.
- Si vous voulez être sûr, vous pouvez vous assurer que vous désactivez explicitement le mappage d’un IP publique lors du lancement du sous-réseau.
Encore une fois, voici la partie connexe du script CloudFormation:
le groupe de sécurité appartient au VPC et n’a aucune autre configuration. Au lieu de cela, un supplément règle d’entrée contient des restrictions de circulation cruciales. Cette règle limite le trafic à la communication au sein du groupe de sécurité suivant le protocole HTTPS. Voici la configuration des deux ressources:
Remarque: il est également possible de configurer les deux parties en tant que ressource unique dans Cloudformation. Cependant, la séparation en deux ressources permet d’éviter plus facilement les références circulaires entre elles.
Le sous-réseau et le groupe de sécurité sont les deux composants auxquels d’autres parties de l’architecture font directement référence plus tard. C’est pourquoi le script du référentiel public exporte ses références. Nous pouvons maintenant continuer à implémenter les points de terminaison requis.
Points de terminaison d’interface
En général, les points de terminaison d’interface sur AWS fonctionnent en raison de AWS PrivateLink. Rappelles toi, Fargate dicte les interfaces dont nous avons besoin ici. Des services supplémentaires ou des architectures plus complexes peuvent nécessiter d’autres configurations. La seule différence entre les trois points de terminaison de l’interface est leur Nom du service. Les paramètres restants sont identiques ::
- le Identifiant du VPC, du sous-réseau et du groupe de sécurité associés.
- le Type de point de terminaison VPC est une interface.
- le DNS privé L’option crée un point de terminaison avec un nom de service par défaut au lieu d’un nom d’hôte DNS spécifique au point de terminaison.
Parlons brièvement du rôle que chacun de ces points de terminaison d’interface joue dans le contexte plus large:
- * .ecr.dkr est le point de terminaison du registre pour utiliser les commandes Docker.
- * .ecr.api est l’accès universel à l’API du registre.
- *.journaux permet la communication de Fargate aux journaux Cloudwatch.
Voici le script CloudFormation pour les trois interfaces:
Comme vous pouvez le voir, cette configuration est très simple. Malheureusement, nous devons créer un autre type de point de terminaison: une passerelle.
Point de terminaison de la passerelle
Seuls deux des services AWS reposent toujours sur des points de terminaison de passerelle: S3 et DynamoDB. ECR utilise S3 en arrière-plan pour stocker des images et des calques de conteneurs. Contrairement aux points de terminaison d’interface, les points de terminaison de passerelle doivent également interagir directement avec un route table.
Les tables de routage contrôlent le flux de trafic lié à un VPC. Pour l’utiliser, nous devons créer la table et l’associer ensuite à un sous-réseau. La configuration est assez simple, alors laissez-moi vous montrer directement le script CloudFormation ici:
Avec ces ressources en place, nous pouvons configurer le point de terminaison de la passerelle S3. Le seul nouveau paramètre est l’ID du routeur responsable de l’organisation du trafic au sein du sous-réseau. Encore une fois, comparez le script CloudFormation pour plus de détails:
Comme vous pouvez le voir, la configuration d’un point de terminaison de passerelle lui-même est plus clairsemée que pour un point de terminaison d’interface. Cependant, nous avons besoin de deux ressources supplémentaires pour couvrir ses fonctionnalités.