Parfois, il est nécessaire de reconstruire complètement le Amazon Web Service (AWS) infrastructure, car elle peut présenter des problèmes structurels et de sécurité susceptibles d'entraîner des situations désagréables.
J'ai récemment suivi tout ce processus et il m'a fallu un certain temps, car il n'était pas toujours aussi intuitif qu'il devrait l'être. Pour être sûr que vous ne rencontrerez pas les mêmes obstacles, je vais vous fournir ici un tutoriel AWS étape par étape qui couvrira tout ce que vous devez savoir pour configurer la gestion de l'infrastructure.
Commençons par le tout début.
Vous venez de créer votre compte AWS et il est temps de commencer à créer votre propre infrastructure. Je suppose que vous aimeriez avoir un environnement de production et également un environnement de test (QA), non ?
Si tel est le cas, il est important de séparez vos environnements. N'utilisez pas le même VPC pour les deux. Vous devez plutôt créer différents VPC dotés de leur propre ensemble de sous-réseaux, de groupes de sécurité, de tables de routage et de passerelles Internet afin de garantir l'indépendance de vos environnements.
Cela évitera que votre environnement d'assurance qualité soit attaqué et que votre environnement de production suive peu de temps après.
Créons donc le premier VPC. Vous pouvez commencer par sélectionner VPC sur le tableau de bord principal :
Ensuite, cliquez sur Création d'un VPC:
Vous obtiendrez cet écran :
L'étape suivante est très importante car c'est là que vous pouvez choisir le type de configuration de votre VPC. Imaginez que vous ayez une application simple (un simple site Web tel que WordPress et MySQL, par exemple), votre meilleure configuration VPC serait la première (avec un seul sous-réseau public).
Cependant, si vous avez une application volumineuse construite avec des microservices et que certains d'entre eux nécessitent un accès public, alors que d'autres n'en ont pas, le second
l'option est la meilleure.
Juste une brève explication sur les sous-réseaux : ce sont des conteneurs réseau (nœuds) à l'intérieur de votre VPC et vous permettent de créer des règles d'accès (trafic et accès public par exemple).
Supposons maintenant que vous souhaitiez créer un VPC avec des sous-réseaux publics et privés. Sélectionnez simplement la bonne option (sur l'image précédente) et cliquez sur Sélectionner pour afficher cet écran.
Vous pouvez configurer les plages IP en fonction de vos besoins et également nommer vos sous-réseaux. En ce qui concerne les zones de disponibilité et les régions, chaque région est organisée par zone géographique et chacune contient les zones disponibles qui sont connectées.
En ce qui concerne la passerelle NAT, vous pouvez utiliser une adresse IP d'allocation élastique (adresse IPv4 publique, accessible depuis Internet) ou créer une instance NAT (une instance EC2 avec des tables de routage spécialement configurées). Personnellement, je choisirais la passerelle NAT, car une instance EC2 présente généralement plus de problèmes de stabilité.
Votre VPC est désormais presque prêt à fonctionner. Tout d'abord, comme le montrent les images ci-dessous, vous devez disposer d'un ensemble de sous-réseaux, l'un privé et l'autre public, d'un ensemble de tables de routage, d'une passerelle Internet associée au VPC par défaut et d'une passerelle NAT associée au sous-réseau public. Vous pouvez également choisir l'instance NAT.
Veuillez noter que Les passerelles NAT ne sont pas incluses dans la version gratuite d'AWS.
Juste une remarque sur les itinéraires : vous constaterez que l'un d'eux pointe vers les deux sous-réseaux pour vous assurer qu'ils peuvent discussion l'un à l'autre.
Les premières étapes sont terminées et nous avons maintenant un tout nouveau VPC prêt à être utilisé ! Passons maintenant à d'autres sujets importants, tels que la création d'instances EC2.
Devons-nous autoriser l'accès direct (SSH) aux instances EC2 ? Nous ne devrions certainement pas ! Même si vous configurez un port différent, bloquez l'accès root et autorisez l'accès uniquement via un fichier de clé privée (fichier PEM), la réponse est toujours la même.
La meilleure solution consiste à utiliser un accès VPN à un serveur Bastion (une instance EC2 qui peut se connecter via SSH à toutes les machines du VPC). Ce bastion ne doit être accessible qu'à l'aide d'une clé autorisée (clé de fichier PEM générée par AWS) et configuré sur un port non standard.
Commencez par vous rendre dans EC2 (section Compute) puis cliquez sur « Lancer l'instance ». Sélectionnez l'AMI (Amazon Machine Image) de base, puis le type d'instance. Après cela, vous arriverez à la troisième étape et celle-ci est très importante. Le sous-réseau de la machine doit être public.
Sélectionnez simplement le sous-réseau public dans la liste, puis modifiez l'option Attribuer automatiquement une adresse IP publique pour activer. Si vous n'avez pas besoin d'espace de stockage supplémentaire, vous pouvez cliquer sur le lien du haut 6. Configurer le groupe de sécurité.
Portez une attention particulière au nom et à la description du groupe car il s'agit d'une étape très importante. Je vous conseille de utiliser de bons noms descriptifs comme, par exemple, teste-public-ssh et une description reconnaissable. Évitez d'utiliser les noms par défaut et toujours vérifiez si une règle a déjà été créée ou vous vous retrouverez avec un tas de règles répétées.
Si vous souhaitez modifier le port par défaut, vous devez également ajouter une règle personnalisée. Il suffit de cliquer Ajouter une règle, mais notez que vous devez le faire après avoir lancé l'instance et que toute modification doit également être apportée à l'instance EC2 (système d'exploitation), sinon vous ne pourrez pas y accéder via SSH.
Continuez en cliquant sur Révision et lancement. Vous remarquerez un message en haut de l'écran.
Vous recevez ce message car cette machine autorise l'accès public au protocole SSH. Cela signifie que nous sommes prêts à partir. Il vous suffit de cliquer sur Lancement bouton, sélectionnez les touches ou créez un nouvel ensemble. Conservez toujours vos clés dans un endroit sûr, n'utilisez pas de VCS pour les ranger.
Jusqu'à présent, j'ai abordé la création du VPC et la création du serveur Bastion. Ensuite, nous allons créer une instance dans un sous-réseau privé et configurer l'accès SSH.
Commençons par cliquer sur Instance de lancement bouton :
Ici, les étapes sont les mêmes, choisissez une AMI (j'utilise Ubuntu 14.04 LTS, inclus dans le niveau gratuit) :
Ensuite, vous choisissez le type d'instance (j'utilise une instance de niveau gratuit, t2.micro) :
Après avoir choisi votre type d'instance, cliquez sur Suivant : Configurer les détails de l'instance.
L'écran suivant s'affichera :
Cette machine n'aura pas d'accès public, elle sera utilisée pour faire fonctionner un service qui ne devrait pas être accessible sur Internet.
Ainsi, dans l'option de sous-réseau, nous devons utiliser le sous-réseau privé créé précédemment avec le VPC et choisir handicapé dans l'option d'attribution automatique d'une adresse IP. Si vous ne souhaitez pas modifier le stockage ou ajouter de balises, vous pouvez cliquer sur Configurer le groupe de sécurité sur le dessus.
Veuillez noter la différence entre celui-ci et le groupe de sécurité utilisé pour Bastion, car ici, nous n'autoriserons l'accès SSH qu'à la plage d'adresses IP privées (cela peut varier en fonction de votre sous-réseau, assurez-vous de le vérifier).
Vous pouvez également ajoutez des règles en fonction de vos besoins (HTTPS, RabbitMQ, etc.) pour une plage d'adresses IP souhaitée (ici, j'ajouterai la règle pour RabbitMQ - port 5672). Si vous ne souhaitez pas ajouter de règles supplémentaires, cliquez simplement sur Révision et lancement. L'écran suivant s'affiche :
Cliquez simplement sur lancer, choisissez votre clé d'accès, puis cliquez sur Instance de lancement. AWS va commencer à créer votre nouvelle instance EC2 :
Si vous accédez au tableau de bord EC2, votre nouvelle instance EC2 devrait figurer dans la liste :
J'ai nommé la nouvelle instance test-rabbitmq. Si vous regardez la colonne DNS public, vous découvrirez qu'elle ne possède pas de DNS public. C'est parce qu'il a été créé dans un sous-réseau privé.
Jusqu'à présent, nous avons créé un VPC avec un sous-réseau privé et un sous-réseau public et nous avons deux machines : l'une utilisée pour l'accès SSH qui se connecte à la zone privée et une machine dans la zone privée (RabbitMQ). Alors, comment testez-vous l'accès SSH ?
Accédez simplement au tableau de bord EC2, récupérez l'adresse IP de Bastion et accédez à votre console. N'oubliez pas d'ajouter la clé privée à la commande :
Vous pouvez désormais vous connecter à votre Bastion ! Allons maintenant plus loin et essayons de vous connecter à votre instance RabbitMQ :
Vous pouvez désormais vous connecter à l'instance privée !
Comme vous l'avez remarqué, j'ai utilisé certains paramètres sur les commandes ci-dessus, mais vous pouvez éviter cela en configurant votre fichier de configuration dans le répertoire .ssh (dans votre répertoire personnel). Vous pouvez également configurer le fichier de configuration sur le serveur Bastion.
Testons donc l'accès à Internet dans l'instance privée EC2 :
Tout fonctionne correctement, mais attention, si vous utilisez une instance NAT au lieu d'une passerelle NAT, n'oubliez pas de modifier les groupes de sécurité, y compris le groupe de machines privées dans les règles.
Vous devez limiter l'accès SSH, créer des sous-réseaux publics et privés, séparer vos environnements (production, développement, QA), chaque environnement (VPC) doit avoir son propre ensemble de tables de routage, de sous-réseaux, etc.
Soyez prudent avec les groupes de sécurité, n'autorisez que les protocoles et les ports nécessaires et évitez les accès externes dans la mesure du possible.
Bien d'autres choses pourraient être écrites sur AWS, mais il est pratiquement impossible de tout couvrir dans un seul article. Certains sujets restent encore à découvrir, tels que la sécurité S3, l'accès à Bastion via un VPN et, bien sûr, l'utilisation d'Ansible pour faire fonctionner les choses. Dans tous les cas, vous trouverez ici tout ce dont vous avez besoin pour vous lancer tout de suite !
À Imaginary Cloud nous travaillons avec un large éventail de technologies, y compris AWS. Si vous avez besoin d'aide avec cette technologie ou des technologies similaires dans le cadre de votre projet de développement logiciel, nous avons une équipe d'experts qui vous attend ! Envoyez-nous un message ici!
Vous avez trouvé cet article utile ? Ceux-ci vous plairont peut-être aussi !
Développeur @Imaginary Cloud, dédiée à la création de solutions logicielles exceptionnelles, engagée dans l'innovation et adoptant des technologies de pointe.
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
