Netzwerkdateisysteme verwenden

In diesem Dokument wird die Verwendung von NFS-, NDB-, 9P-, CIFS/Samba- und Ceph-Netzwerkdateisystemen mit Cloud Run beschrieben. Wenn Sie Filestore oder Cloud Storage FUSE in Cloud Run verwenden, lesen Sie die vollständigen Anleitungen für Filestore in Cloud Run oder Cloud Storage FUSE in Cloud Run. Sie können ein Netzwerkdateisystem verwenden, um Daten zwischen mehreren Containern und Diensten in Cloud Run freizugeben und dauerhaft zu speichern. Dieses Feature ist nur verfügbar, wenn Sie die Cloud Run-Ausführungsumgebung der zweiten Generation verwenden.

Wenn Sie Dateien mit einem Dateisystem in Ihrem Cloud Run-Dienst lesen und schreiben möchten, haben Sie folgende Möglichkeiten:

  • Wenn Sie die Daten nicht über die Lebensdauer der Instanz hinaus beibehalten müssen, können Sie das integrierte Arbeitsspeicherdateisystem verwenden.
  • Wenn Sie Daten über die Lebensdauer einer Containerinstanz hinaus beibehalten und die Semantik des Standarddateisystems verwenden möchten, nutzen Sie ein Netzwerkdateisystem, wie auf dieser Seite beschrieben. Sie können Filestore oder selbstverwaltete NFS-, NDB-, 9P-, CIFS/Samba- und Ceph-Netzwerkdateisysteme mit Cloud Run verwenden.
  • Wenn Sie auf Cloud Storage zugreifen müssen, als ob es ein Dateisystem wäre, ohne eines ausführen zu müssen, verwenden Sie Cloud Storage FUSE.
  • Wenn Sie Daten über die Lebensdauer einer Containerinstanz hinaus beibehalten und keine Semantik des Standarddateisystems benötigen, ist die einfachste Option die Verwendung von Cloud Storage-Clientbibliotheken. Diese Option eignet sich auch, wenn Sie gleichzeitig auf Daten von vielen Instanzen zugreifen müssen.

Kosten für die Verwendung von Netzwerkdateisystemen

Die Kosten für die Nutzung eines Netzwerkdateisystems sind auf die Kosten des Netzwerkdateisystems beschränkt, je nachdem, wo das Dateisystem ausgeführt wird, und auf die üblichen Kosten zur Ausführung eines Cloud Run-Dienstes. Weitere Informationen zu diesen Kosten finden Sie im Abschnitt zu Kosten in der Anleitung zu Filestore oder Cloud Storage FUSE.

Beschränkungen

Die folgenden Überlegungen gelten für die Verwendung von Netzwerkdateisystemen in Cloud Run:

  • Beim Bereitstellen in Cloud Run müssen Sie die Ausführungsumgebung der zweiten Generation angeben.

  • Cloud Run wurde für eine schnelle Skalierung auf eine große Anzahl von Instanzen entwickelt. Die meisten Netzwerkdateisysteme sind jedoch nicht für die gleichzeitige Verwendung durch eine große Anzahl von Clients konzipiert. Verwenden Sie das Feature für eine maximale Anzahl von Instanzen, um die Anzahl der Cloud Run-Instanzen zu begrenzen.

  • Cloud Run unterstützt keine NFS-Sperre. Verwenden Sie daher beim Bereitstellen von NFS die Option -o nolock. Google empfiehlt, Ihre Anwendung so zu entwerfen, dass gleichzeitige Schreibvorgänge am selben Dateispeicherort vermieden werden. Eine Möglichkeit dafür besteht darin, ein anderes System wie Redis oder Memorystore zum Speichern eines Mutex zu verwenden.

Netzwerkdateisystem einrichten

Wenn Sie noch keinen Dateiserver eingerichtet haben, folgen Sie der Lösungsanleitung für Dateiserver in Compute Engine, um das richtige Dateisystem für Ihre Anforderungen auszuwählen und einzurichten. Wenn Sie einen vorhandenen Dateiserver verwenden, achten Sie darauf, dass er von einem VPC-Netzwerk aus zugänglich ist.

Connector für serverlosen VPC-Zugriff konfigurieren

Sie müssen den Connector für serverlosen VPC-Zugriff verwenden, um Ihren Cloud Run-Dienst mit dem VPC-Netzwerk zu verbinden, in dem das Netzwerkdateisystem ausgeführt wird.

Folgen Sie der Anleitung auf der Seite Verbindung zu einem VPC-Netzwerk herstellen, um einen Connector für serverlosen VPC-Zugriff im selben VPC-Netzwerk zu erstellen und eine Verbindung zum Cloud Run-Dienst herzustellen.

Dateisystem über den Cloud Run-Dienst bereitstellen

Das Bereitstellen eines Dateisystems über einen Cloud Run-Dienst ist ein Thema für Fortgeschrittene. Sie könnten von einer der umfassenden Anleitungen zur Verwendung von Filestore oder Cloud Storage FUSE profitieren.

So stellen Sie ein Netzwerkdateisystem bereit:

  1. Definieren Sie ein Startskript, das Ihre Anwendung startet und den Bereitstellungspunkt Ihres Dockerfile angibt. Das folgende Beispiel zeigt ein Skript, das Filestore als Netzwerkdateisystem verwendet:

    Python

    set -eo pipefail
    
    # Create mount directory for service.
    mkdir -p $MNT_DIR
    
    echo "Mounting Cloud Filestore."
    mount -o nolock $FILESTORE_IP_ADDRESS:/$FILE_SHARE_NAME $MNT_DIR
    echo "Mounting completed."
    
    # Run the web service on container startup. Here we use the gunicorn
    # webserver, with one worker process and 8 threads.
    # For environments with multiple CPU cores, increase the number of workers
    # to be equal to the cores available.
    # Timeout is set to 0 to disable the timeouts of the workers to allow Cloud Run to handle instance scaling.
    exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 main:app
    
    # Exit immediately when one of the background processes terminate.
    wait -n

    Java

    set -eo pipefail
    
    # Create mount directory for service
    mkdir -p $MNT_DIR
    
    echo "Mounting Cloud Filestore."
    mount -o nolock $FILESTORE_IP_ADDRESS:/$FILE_SHARE_NAME $MNT_DIR
    echo "Mounting completed."
    
    # Start the application
    java -jar filesystem.jar
    
    # Exit immediately when one of the background processes terminate.
    wait -n

  2. Ersetzen Sie den Dateibereitstellungscode im Startskript run.sh anhand der folgenden Beispiele. Ersetzen Sie dabei die Variablen nach Bedarf:

    • Für NFS

       echo "mounting NFSv4 share"
       mount -t nfs4 -o nolock IP_ADDRESS:FILE_SHARE_NAME MOUNT_POINT_DIRECTORY

      Achten Sie darauf, dass Sie bei der Bereitstellung von NFS die Option -o nolock verwenden. Cloud Run unterstützt keine NFS-Sperren.

    • Für NBD

       echo "mounting ext4 image via NBD"
       nbd-client -L -name image IP_ADDRESS DEVICE_NAME
       mount DEVICE_NAME MOUNT_POINT_DIRECTORY

    • Für PD-SSD über NBD

       echo "mounting PD-SSD via NBD"
       nbd-client -L -name disk IP_ADDRESS DEVICE_NAME
       mount DEVICE_NAME MOUNT_POINT_DIRECTORY

    • Für 9P

       echo "mounting 9p export"
       mount -t 9p -o trans=tcp,aname=/mnt/diod,version=9p2000.L,uname=root,access=user IP_ADDRESS MOUNT_POINT_DIRECTORY

    • Für SMB

       echo "mounting SMB public share"
       mount -t cifs -ousername=USERNAME,password=PASSWORD,ip=IP_ADDRESS //FILESHARE_NAME MOUNT_POINT_DIRECTORY
       echo "mounts completed"

  3. Definieren Sie die Umgebungskonfiguration mit dem Dockerfile. Mit RUN geben Sie alle weiteren erforderlichen Systempakete wie nbd-client für NBD. Verwenden Sie CMD, um den Befehl anzugeben, der beim Ausführen des Images (Startskript run.sh) ausgeführt werden soll, und um Standardargumente für ENTRYPOINT bereitzustellen, was die Init-Prozessbinärdatei angibt.

    Das folgende Beispiel zeigt ein Dockerfile für einen Dienst, der Filestore verwendet:

    Python

    # Use the official lightweight Python image.
    # https://hub.docker.com/_/python
    FROM python:3.9-slim
    
    # Install system dependencies
    RUN apt-get update -y && apt-get install -y \
        tini \
        nfs-common \
        && apt-get clean
    
    # Set fallback mount directory
    ENV MNT_DIR /mnt/nfs/filestore
    
    # Copy local code to the container image.
    ENV APP_HOME /app
    WORKDIR $APP_HOME
    COPY . ./
    
    # Install production dependencies.
    RUN pip install -r requirements.txt
    
    # Ensure the script is executable
    RUN chmod +x /app/run.sh
    
    # Use tini to manage zombie processes and signal forwarding
    # https://github.com/krallin/tini
    ENTRYPOINT ["/usr/bin/tini", "--"]
    
    # Pass the startup script as arguments to tini
    CMD ["/app/run.sh"]

    Java

    
    # Use the official maven/Java 11 image to create a build artifact.
    # https://hub.docker.com/_/maven
    FROM maven:3.8.4-jdk-11 as builder
    
    # Copy local code to the container image.
    WORKDIR /app
    COPY pom.xml .
    COPY src ./src
    
    # Build a release artifact.
    RUN mvn package -DskipTests
    
    # Use AdoptOpenJDK for base image.
    # https://docs.docker.com/develop/develop-images/multistage-build/#use-multi-stage-builds
    FROM eclipse-temurin:17-jdk
    
    # Install filesystem dependencies
    RUN apt-get update -y && apt-get install -y \
        tini \
        nfs-kernel-server \
        nfs-common \
        && apt-get clean
    
    # Set fallback mount directory
    ENV MNT_DIR /mnt/nfs/filestore
    
    # Copy the jar to the production image from the builder stage.
    COPY --from=builder /app/target/filesystem-*.jar /filesystem.jar
    
    # Copy the statup script
    COPY run.sh ./run.sh
    RUN chmod +x ./run.sh
    
    # Use tini to manage zombie processes and signal forwarding
    # https://github.com/krallin/tini
    ENTRYPOINT ["/usr/bin/tini", "--"]
    
    # Run the web service on container startup.
    CMD ["/run.sh"]

Über den Cloud Run-Dienstcode auf ein Netzwerkdateisystem zugreifen

Für den Zugriff auf die Netzwerkdateisysteme in Ihrem Dienstcode verwenden Sie wie gewohnt die Lese- und Schreibvorgänge für die Datei.

Containerisieren und bereitstellen

Wenn der Cloud Run-Dienstcode abgeschlossen ist, containerisieren und stellen Sie bereit, wie Sie es normalerweise für einen Cloud Run-Dienst tun. Achten Sie dabei darauf, dass Sie die Ausführungsumgebung der zweiten Generation angeben.

Nächste Schritte