ECS Fargate Persistenter Speicher: EFS-Zugangspunkte vs. Lambda Workarounds

Wenn Sie einen Docker-Container auf ECS Fargate ausführen, ist persistente Speicherung oft eine Notwendigkeit. Ich habe zunächst versucht, dieses Problem zu lösen, indem ich das erforderliche Verzeichnis auf EFS mit einer Lambda-gestützten benutzerdefinierten Ressource manuell erstellt habe. Das funktionierte zwar, führte aber zu unnötiger Komplexität. Beim Experimentieren entdeckte ich eine elegantere Lösung - die Verwendung von EFS-Zugriffspunkten. In diesem Beitrag beschreibe ich meinen Weg, die Herausforderungen, denen ich mich gegenübersah, und wie ich die Einrichtung schließlich mit weniger Ressourcen und weniger Wartungsaufwand vereinfacht habe.

EFS einrichten

Wenn Sie einen Container auf ECS Fargate starten, müssen Sie eine TaskDefinition definieren. Diese Definition wird zum Starten des Containers verwendet. Innerhalb dieser Definition können Sie Volumes definieren. Diese Volumes können dann in den Container eingehängt werden, indem Sie einen Einhängepunkt pro Container angeben.

So weit, so gut! Aber ich bin schnell auf ein Problem gestoßen. Die Aufgabe konnte nicht gestartet werden, weil der Pfad im EFS noch nicht existierte. Ich habe versucht, /my-task/data auf /data im Container einzuhängen. Der Pfad /my-task/data existiert jedoch nicht auf dem EFS-Laufwerk. Die einfache Lösung wäre, den Container an eine EC2-Instanz anzuschließen und den Ordner von dort aus zu erstellen. Sie könnten denken, dass das Problem damit gelöst ist, aber das ist nicht die Lösung für das eigentliche Problem. Wie Sie in meinem vorherigen Blog lesen konnten, mag ich es, wenn ich mehrere Versionen eines Stacks erstellen kann. Mit diesem manuellen Zwischenschritt können Sie das nicht tun.

Wie wäre es mit einer benutzerdefinierten Ressource?

Wir wissen, dass wir einen Ordner auf dem EFS-Laufwerk erstellen müssen. Eine Lambda-Funktion könnte dies tun, also begann ich mit der Implementierung einer benutzerdefinierten Ressource. Die Idee ist ganz einfach: Erstellen Sie eine Lambda-Funktion, die das Stammverzeichnis des EFS einbindet, und dann würde der Lambda-Code einfach den Ordner auf dem EFS erstellen. Wir markieren diese benutzerdefinierte Ressource als Abhängigkeit vom ECS Fargate-Dienst, um sicherzustellen, dass der Ordner vorhanden ist, bevor wir den Container starten, und schon sind wir fertig.

Ich habe diesen Ablauf vollständig implementiert, und er funktioniert perfekt. Wenn Sie Ihren Stack bereitstellen, tut die benutzerdefinierte Ressource ihren Dienst und der Container kann erfolgreich gestartet werden.

Gibt es einen besseren Weg?

Als ich die benutzerdefinierte Ressource implementierte, musste ich einen Zugriffspunkt erstellen. Eine Lambda-Funktion kann ein EFS-Laufwerk nur über einen Zugriffspunkt einbinden. Dieser Zugriffspunkt ermöglicht es Ihnen, einen Pfad im EFS sowie die Benutzer- und Gruppen-ID für den Zugriff auf diesen Pfad zu definieren. Wenn Sie /my-lambda/ als Pfad angeben, kann die Funktion nur den Inhalt des Ordners my-lambda sehen. Dies ist ideal, um andere Pfade vor dem Zugriff zu schützen. Aus Sicht der Lambda-Funktionen sehen Sie den Ordner my-lambda nicht, sondern nur den Inhalt.

Warum ist das so wichtig, werden Sie sich fragen? Nun, dieser Pfad wird auf dem EFS-Laufwerk für Sie erstellt. Ich habe in der ECS-Dokumentation nachgesehen, und Sie können auch einen Zugriffspunkt für Container-Volumes verwenden. Ich habe den Zugriffspunkt verwendet, um /my-task/data zu definieren, und die uid und gid auf die gleiche ID gesetzt, die der Benutzer im Container ausgeführt hat. Da wir den Container auch ohne eine benutzerdefinierte Ressource ausführen können, habe ich die Funktion aus meiner Vorlage gelöscht.

Fazit

Experimentieren führt oft zu besseren Lösungen. Mein ursprünglicher Ansatz - die Verwendung einer Lambda-Funktion zur Erstellung des erforderlichen EFS-Verzeichnisses - hat zwar funktioniert, aber zu unnötiger Komplexität geführt. Indem ich die EFS-Zugriffspunkte nutzte, erreichte ich das gleiche Ergebnis mit einer saubereren, besser zu verwaltenden Einrichtung. Diese Erfahrung bestätigte eine wichtige Lektion: Die einfachste Lösung ist oft die beste. Bei der Arbeit mit einer Cloud-Infrastruktur lohnt es sich immer, integrierte Funktionen zu erkunden, bevor man auf benutzerdefinierte Implementierungen zurückgreift.

Foto von Nataliya Vaitkevich