kontakta oss

Ibland är det nödvändigt att helt bygga om Amazons webbtjänst (AWS) infrastruktur, eftersom det kan ha strukturella problem och säkerhetsproblem som kan leda till obehagliga situationer.
Jag gick nyligen igenom hela processen och det tog ett tag att slutföra, eftersom det inte alltid var så intuitivt som det borde vara. För att vara säker på att du inte kommer att möta samma hinder, här kommer jag att ge en steg för steg AWS handledning som täcker allt du behöver veta för att konfigurera infrastrukturhanteringen.
Låt oss börja från början.
Du har precis skapat ditt AWS-konto och nu är det dags att börja bygga din egen infrastruktur. Jag antar att du skulle vilja ha en produktionsmiljö och även en testmiljö (QA), eller hur?
Om så är fallet är det viktigt att separera dina miljöer. Använd inte samma VPC för båda. Istället bör du skapa olika VPC: er med sin egen uppsättning undernät, säkerhetsgrupper, rutttabeller och internetgateways för att säkerställa att dina miljöer är oberoende.
Detta undviker situationen där din QA-miljö attackeras och din produktionsmiljö följer strax efter.
Så låt oss skapa den första VPC. Du kan börja med att välja VPC på huvudinstrumentpanelen:

Klicka sedan på Skapa VPC:

Du får den här skärmen:

Nästa steg är verkligen viktigt eftersom det är där du kan välja din VPC-konfigurationstyp. Föreställ dig att du har en enkel applikation (en enkel webbplats som WordPress och MySQL, till exempel), din bästa VPC-konfiguration skulle vara den första (med ett enda offentligt undernät).
Men om du har en stor applikation byggd med mikrotjänster och vissa av dem kräver allmän åtkomst, medan andra inte gör det, den andra
alternativet är det bästa.
Bara en snabb förklaring om undernät: de är nätverksbehållare (noder) inuti din VPC och låter dig skapa åtkomstregler (trafik och allmän åtkomst till exempel).
Låt oss nu anta att du vill skapa en VPC med offentliga och privata undernät. Välj bara rätt alternativ (på föregående bild) och klicka på välj för att se den här skärmen.

Du kan konfigurera IP-intervallen efter dina behov och även namnge dina undernät. När det gäller tillgänglighetszoner och regioner är varje region organiserad efter geografiskt område och var och en innehåller de tillgängliga zoner som är anslutna.

När det gäller NAT Gateway kan du använda en elastisk allokerings-IP (offentlig IPv4-adress, som kan nås från internet) eller skapa en NAT-instans (en EC2-instans med speciellt konfigurerade routingtabeller). Personligen skulle jag välja NAT-gateway, eftersom en EC2-instans vanligtvis har mer stabilitetsproblem.
Din VPC är nu nästan redo för handling. För det första, som framgår av bilderna nedan, bör du ha en uppsättning undernät, en privat och en offentlig, en uppsättning rutttabeller, en internetgateway som är associerad med VPC som standard och en NAT-gateway associerad till det offentliga undernätet. Alternativt kan du välja NAT-instans.
Observera att NAT-gateways ingår inte i den kostnadsfria nivån av AWS.




Bara en sidoanteckning på rutterna: du kommer att upptäcka att en av dem pekar på de två delnäten för att säkerställa att de kan prata till varandra.
De första stegen är klara och vi har nu en ny ny VPC redo att rocka! Låt oss nu täcka andra viktiga ämnen, till exempel att skapa EC2-instanser.
Ska vi tillåta direktåtkomst (SSH) till EC2-instanserna? Vi borde definitivt inte! Även om du ställer in en annan port, blockerar root-åtkomsten och tillåter åtkomst endast via privat nyckelfil (PEM-fil), är svaret fortfarande detsamma.
Den bästa lösningen är att använda en VPN-åtkomst till en Bastion-server (en EC2-instans som kan ansluta via SSH till alla maskiner i VPC). Denna Bastion bör endast nås med en auktoriserad nyckel (PEM-filnyckel genererad av AWS) och konfigurerad i en icke-standardport.
Börja med att gå till EC2 (Beräkningssektion) och klicka sedan på ”Starta instans”. Välj bas-AMI (Amazon Machine Image) och sedan instanstyp. Efter det kommer du att nå det tredje steget och det här är ett mycket viktigt. Maskinens undernät ska vara offentligt.

Välj bara det offentliga undernätet i listan och ändra sedan alternativet Tilldela offentlig IP automatiskt till aktivera. Om du inte behöver extra lagring kan du klicka på den översta länken 6. Konfigurera säkerhetsgrupp.

Var särskilt uppmärksam på gruppnamnet och beskrivningen eftersom detta är ett mycket viktigt steg. Jag råder dig att Använd bra beskrivande namn som, till exempel, test-public-ssh och en igenkännlig beskrivning. Undvik att använda standardnamn och alltid kontrollera om det redan finns någon regel skapad eller så kommer du att sluta med en massa upprepade regler.
Om du vill ändra standardporten måste du också lägga till en anpassad regel. Klicka bara in Lägg till regel, men notera att du bör göra detta efter att du startat instansen och eventuella ändringar måste göras också i EC2-instansen (operativsystem) annars kommer du inte att kunna komma åt den via SSH.
Fortsätt genom att klicka på Granska och lansera. Du kommer att märka ett meddelande högst upp på skärmen.

Du får det här meddelandet eftersom den här datorn tillåter offentlig SSH-åtkomst. Det betyder att vi är redo att gå. Klicka bara på Lansera knappen, välj tangenterna eller skapa en ny uppsättning. Förvara alltid dina nycklar på ett säkert ställe, använd inte ett VCS för att lagra dem.
Fram till denna punkt har jag täckt skapandet av VPC och skapandet av Bastion-servern. Därefter skapar vi en instans i ett privat delnät och konfigurerar SSH-åtkomsten.
Låt oss börja med att klicka på Starta instans knapp:

Här är stegen desamma, välj en AMI (jag använder Ubuntu 14.04 LTS, ingår i gratisnivån):

Sedan väljer du instanstypen (jag använder en gratis nivåinstans, t2.micro):

När du har valt instanstyp klickar du på Nästa: Konfigurera förekomstinformation.
Du kommer att visas med följande skärm:

Den här maskinen kommer inte att ha allmän tillgång, den kommer att användas för att köra en tjänst som inte borde vara tillgänglig för internet.
Så i alternativet subnät bör vi använda det privata delnätet som tidigare skapats med VPC och välja inaktiverad i alternativet för automatisk tilldelning av IP. Om du inte vill ändra lagring eller lägga till taggar kan du klicka på Konfigurera säkerhetsgrupp på toppen.

Observera skillnaden mellan den här och säkerhetsgruppen som används för Bastion, eftersom vi här bara tillåter SSH-åtkomst till det privata IP-området (det kan variera beroende på ditt undernät, se till att kontrollera det).
Du kan också lägg till regler enligt dina behov (HTTPS, RabbitMQ, etc.) för ett önskat IP-intervall (här lägger jag till regeln för RabbitMQ - port 5672). Om du inte vill lägga till fler regler klickar du bara på Granska och lansera. Nästa skärm visas:

Klicka bara på start, välj din åtkomstnyckel och klicka sedan på Starta instans. AWS börjar skapa din nya EC2-instans:

Om du går till EC2-instrumentpanelen bör din nya EC2-instans finnas i listan:

Jag namngav den nya instansen test-kaninmq. Om du tittar på den offentliga DNS-kolumnen kommer du att upptäcka att den inte har en offentlig DNS. Det beror på att det skapades i ett privat undernät.
Hittills har vi byggt en VPC med ett privat och ett offentligt undernät och vi har två maskiner: en som används för SSH-åtkomst som ansluter till den privata zonen och en maskin i den privata zonen (RabbitMQ). Så, hur testar du SSH-åtkomst?
Gå bara till EC2-instrumentpanelen, hämta Bastion IP och gå till din konsol. Glöm inte att lägga till den privata nyckeln till kommandot:
Du kan nu ansluta till din Bastion! Låt oss nu gå djupare och försöka ansluta till din RabbitMQ-instans:
Du kan nu ansluta till den privata instansen!
Som du har märkt har jag använt några parametrar på kommandona ovan, men du kan undvika detta genom att konfigurera din konfigurationsfil i.ssh katalogen (i din hemkatalog). Du kan också konfigurera konfigurationsfilen i Bastion-servern.
Så låt oss testa internetåtkomsten i den privata EC2-instansen:
Allt fungerar korrekt, men bara en anteckning, om du använder en NAT-instans istället för en NAT-gateway, glöm inte att ändra säkerhetsgrupperna, inklusive den privata datorgruppen i reglerna.

Du bör begränsa SSH-åtkomsten, skapa offentliga och privata undernät, separera dina miljöer (produktion, utveckling, QA), varje miljö (VPC) bör ha sin egen uppsättning rutttabeller, subnät etc.
Var försiktig med säkerhetsgrupperna, tillåt bara nödvändiga protokoll och portar och undvik extern åtkomst när det är möjligt.
Mycket mer kan skrivas om AWS men det är praktiskt taget omöjligt att bara täcka allt i en artikel. Det finns fortfarande några avslöjade ämnen, till exempel S3-säkerhet, Bastion-åtkomst via VPN och naturligtvis att använda Ansible för att få saker igång. Hur som helst, här hittar du allt du behöver för att komma igång direkt!
Vid Imaginärt moln vi arbetar med en bred teknisk stack, inklusive AWS. Om du behöver hjälp med denna teknik eller liknande i ditt mjukvaruutvecklingsprojekt har vi ett team av experter som väntar på dig! Skicka oss en rad här!

Hittade den här artikeln användbar? Du kanske gillar dessa också!

Utvecklare @Imaginary Moln, dedikerad till att skapa exceptionella mjukvarulösningar, engagerad i innovation och omfamna avancerad teknik.
Människor som läste det här inlägget tyckte också att dessa var intressanta: