mirror of
https://gitlab.com/ser-cal/m346.git
synced 2024-11-26 09:51:56 +01:00
KN05 B) ergänzt mit Text und Bildern
This commit is contained in:
parent
5efc4f6825
commit
e8c1d50cc5
@ -149,13 +149,18 @@ Das Erstellen des ersten Subnets wird unten beschrieben. Die restlichen Subnets
|
|||||||
![Create Subnet 1](./x_res/18_Subnet_create_600.png) | ![Create Subnet 2](./x_res/19_Subnet_create_600.png)
|
![Create Subnet 1](./x_res/18_Subnet_create_600.png) | ![Create Subnet 2](./x_res/19_Subnet_create_600.png)
|
||||||
5. ...erstellen Sie nun noch die 3 anderen Subnets gemäss [dieser Konfigurationsdatei](./x_res/custom-vpc.md).
|
5. ...erstellen Sie nun noch die 3 anderen Subnets gemäss [dieser Konfigurationsdatei](./x_res/custom-vpc.md).
|
||||||
6. Resultat
|
6. Resultat
|
||||||
**6.** Ansicht der erzeugten Subnetze (nach Namen sortiert) |
|
**6.** Schritt: Ansicht der erzeugten Subnetze (nach Namen sortiert) |
|
||||||
:---:
|
:---:
|
||||||
![Schema](./x_res/20_Subnet_create_1200.png) |
|
![Schema](./x_res/20_Subnet_create_1200.png) |
|
||||||
|
|
||||||
<br>
|
<br>
|
||||||
|
|
||||||
##### Schritt 3: Route Table Configuration
|
##### Schritt 3: Route Table Configuration
|
||||||
Nun geht es darum, die Route Tables für die Public- und die Private-Subnets zu definieren. Wenn eine VPC erstellt wird, wird **immer** auch eine **Public Route Table** erstellt. Diese ist grundsätzlich vergleichbar mit einem **Router**, allerdings noch nicht fertig konfiguriert. Der Router ist für uns physikalisch nicht sichtbar und wir können auch nicht z.B. via SSH darauf zugreifen. Was wir allerdings machen können, ist sogenannte **Routing Rules** (Routing Regeln) zu definieren. Das entspricht dann grundsätzlich genau demselben Prinzip wie **statische-** und **dynamische Routen** zu erstellen (später mehr dazu).
|
Nun geht es darum, die Route Tables für die Public- und die Private-Subnets zu definieren. Beim Erstellen einer VPC wird **immer** auch gleichzeitig eine **Public Route Table** erstellt. Diese ist grundsätzlich vergleichbar mit einem **Router**, allerdings noch nicht fertig konfiguriert. Dieser **Virtuelle Router** ist physikalisch nicht sichtbar und wir können auch nicht z.B. via SSH darauf zugreifen. Was wir allerdings machen können, ist sogenannte **Routing Rules** (Routing Regeln) zu definieren. Das entspricht dann grundsätzlich genau demselben Prinzip wie **statische-** und **dynamische Routen** zu erstellen (später mehr dazu).
|
||||||
|
|
||||||
Weil wir später noch eine **Private Route Table** erstellen werden, geben wir der bestehenden **Public Route Table** mal zuerst einen Namen. Dies ist der einzige Wert, der nicht in der [Konfigurationsdatei](./x_res/custom-vpc.md) definiert wurde. Weil da aber der Name der später folgenden **Private Route Table** bereits definiert wurde, können wir den Namen davon ableiten. Im Falle des Autors dieses Challenges, heisst die **Public Route Table** **`M346-CAL-Public-RT`** und wird wie folgt eingetragen.
|
Weil wir später noch eine **Private Route Table** erstellen werden, geben wir der bestehenden **Public Route Table** mal zuerst einen Namen. Dies ist der einzige Wert, der nicht in der [Konfigurationsdatei](./x_res/custom-vpc.md) definiert wurde. Weil da aber der Name der später folgenden **Private Route Table** bereits definiert wurde, können wir den Namen davon ableiten. Im Falle des Autors dieses Challenges, heisst die **Public Route Table** **`M346-CAL-Public-RT`** und wird wie folgt eingetragen.
|
||||||
|
|
||||||
|
1. Public Route Table Namen zuweisen
|
||||||
|
**1.** Schritt: Public Router mit einem Namen versehen - Gem. Konvention: M346-XXX-Public-RT |
|
||||||
|
:---:
|
||||||
|
![Public Router](./x_res/21_Public_Route-table_1200.png) |
|
Loading…
Reference in New Issue
Block a user