Hosting einer einseitigen Anwendung oder Website auf S3

In diesem Blogbeitrag zeige ich Ihnen, wie Sie eine einseitige Anwendung oder Website konfigurieren. In einem früheren Blog Best Practices für S3-Webhosting und eine Erklärung, warum. hat Tibor Hercz die besten Praktiken für das Hosten einer statischen Website auf S3 erläutert.

Wie Tibor erklärt hat, gibt es einige Nachteile bei der Verwendung einer Origin Access Identity (OAI). Aber in einigen Single Page Applications (SPA) werden Sie diese Nachteile nicht erfahren.

Was ist eine einseitige Anwendung?

Eine einseitige Anwendung lädt ein einzelnes Webdokument. Basierend auf Ihrer Interaktion mit dieser Seite wird der Inhalt aktualisiert. Die Seiten werden in Ihrem Webbrowser gerendert. Und es werden weitere API-Aufrufe durchgeführt, um zusätzliche Eingaben abzurufen. Aus diesem Grund kann eine SPA sehr schnell sein!

Sie können das Framework Ihrer Wahl verwenden: Angular, Reactjs, Vue, usw. usw.

Einrichten der Infrastruktur

Der Einfachheit halber stelle ich CloudFormation-Snippets zur Verfügung.

Zunächst benötigen wir einen S3-Bucket, in dem wir die Anwendung hosten. Wir brauchen eine OAI. Und wir müssen ihr Zugriff auf den Bucket gewähren:

  MyBucket:
    Type: AWS::S3::Bucket
    Properties:
      AccessControl: Private

  MyOriginAccessIdentity:
    Type: AWS::CloudFront::CloudFrontOriginAccessIdentity
    Properties:
      CloudFrontOriginAccessIdentityConfig:
        Comment: Allows CloudFront to reach the bucket

  MyBucketPolicy:
    Type: AWS::S3::BucketPolicy
    Properties:
      Bucket: !Ref MyBucket
      PolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Action:
              - s3:GetObject*
              - s3:GetBucket*
              - s3:List*
            Effect: Allow
            Principal:
              CanonicalUser: !GetAtt MyOriginAccessIdentity.S3CanonicalUserId
            Resource:
              - !GetAtt MyBucket.Arn
              - !Sub ${MyBucket.Arn}/*

Als nächstes benötigen wir die CloudFront-Distribution:

  MyDistribution:
    Type: AWS::CloudFront::Distribution
    Properties:
      DistributionConfig:
        CustomErrorResponses:
          - ErrorCode: 404
            ResponseCode: 200
            ResponsePagePath: /index.html
        DefaultCacheBehavior:
          AllowedMethods:
            - GET
            - HEAD
          CachedMethods:
            - GET
            - HEAD
          Compress: true
          ForwardedValues:
            Cookies:
              Forward: none
            QueryString: false
          TargetOriginId: origin
          ViewerProtocolPolicy: redirect-to-https
        DefaultRootObject: index.html
        Enabled: true
        HttpVersion: http2
        IPV6Enabled: true
        Origins:
          - ConnectionAttempts: 3
            ConnectionTimeout: 10
            DomainName: !GetAtt MyBucket.RegionalDomainName
            Id: origin
            S3OriginConfig:
              OriginAccessIdentity:
                Fn::Join:
                  - ""
                  - - origin-access-identity/cloudfront/
                    - Ref: MyOriginAccessIdentity

Sobald Sie die Infrastruktur eingerichtet haben. Sie müssen Ihre SPA auf hochladen. Und laden Sie den Build in den S3-Bucket hoch. Ich gehe davon aus, dass Sie eine App mit verschiedenen Routen/Pfaden erstellt haben.

Wie funktioniert das?

Wenn Sie zu dem Hostnamen der erstellten CloudFront-Distribution navigieren. Die Verteilung wird auf die Datei zurückgreifen. Das liegt daran, dass wir DefaultRootObject auf index.html gesetzt haben. Wenn Sie in der Anwendung navigieren, sieht es so aus, als würde der Browser die Pfade ändern. In Wirklichkeit wird jedoch nur die Adresse in der Adressleiste aktualisiert.

Angenommen, Sie haben eine Route /blog erstellt. Sie navigieren zu dieser Route. Und Sie machen einen harten Refresh! Sie erwarten eine 404 Not Found Fehlermeldung, weil es keinen Ordner mit dem Namen blog gibt. Aber weil wir eine CustomErrorResponses konfiguriert haben, werden alle 404 Fehler an die index.html Datei mit einem 200 Antwortcode weitergeleitet.

Dadurch wird sichergestellt, dass die Single Page Application erneut geladen wird. Sie erkennt die Position in der Adressleiste und zeigt den richtigen Inhalt an.

Das bedeutet jedoch, dass Sie unbekannte Routen in Ihrer Anwendung behandeln müssen.

Fazit

Wenn Sie eine Single Page Application hosten möchten, können Sie CloudFront mit privaten Buckets verwenden. Sie erhalten alle Vorteile von CloudFront, während der Bucket privat bleibt.