Bitbucket ist ein Atlassian-Produkt und ein Git-basierter Code-Speicher mit CI/CD-optimierten Tools fur Teams, die mit Jira zusammenarbeiten. Wenn du deinen Code anderst und Revisionen sowie den Verlauf in Bitbucket fuhrst, benotigst du auch etwas Automatisierung fur das Deployment.

CI/CD steht fur jede Automatisierung und bedeutet Continuous Integration und Continuous Delivery. In diesem Artikel werden wir CI und CD gleichzeitig nutzen.

Ich uberspringe "Wie benutzt man Bitbucket?" und fuhre dich in Bitbucket Pipelines fur das Continuous Deployment zu AWS S3 ein, das CloudFront fur die weltweite Verteilung verwendet.

Wenn du einen S3 Bucket mit Static-Hosting-Unterstutzung erstellst, solltest du von deinem lokalen Ordner zum S3 Bucket syncen. Normalerweise sollten wir den Befehl aws s3 sync LOCAL_FOLDER/ s3://STATIC_HOSTING_ENABLED_BUCKET_NAME --delete ausfuhren, um den lokalen Ordner zu 100% mit dem S3 Bucket zu synchronisieren.

Wenn du CloudFront fur die Verteilung verwendest, siehst du beim Besuch der Website den alten Inhalt. Der Grund ist, dass CloudFront alle Inhalte an allen Edge-Standorten zwischenspeichert und die Inhalte von den Edge-Standorten ausliefert. Wir mussen den "Cache invalidieren", um den neuen Inhalt neu an den Edge-Standorten zu cachen.

Welche IAM Policy fur S3 und CloudFront verwenden?

Fur maximale Sicherheit liebe ich es, maximale Einschrankung und minimale Erlaubnis fur IAM Policies zu setzen. Du kannst die Policies unten sehen:

S3 Bucket IAM Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "S3BucketPolicy",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::BUCKET_NAME",
                "arn:aws:s3:::BUCKET_NAME/*"
            ],
            "Condition": {
                "ForAnyValue:IpAddress": {
                    "aws:SourceIp": [
                        "34.199.54.113/32",
                        "34.232.25.90/32",
                        "34.232.119.183/32",
                        "34.236.25.177/32",
                        "35.171.175.212/32",
                        "52.54.90.98/32",
                        "52.202.195.162/32",
                        "52.203.14.55/32",
                        "52.204.96.37/32",
                        "34.218.156.209/32",
                        "34.218.168.212/32",
                        "52.41.219.63/32",
                        "35.155.178.254/32",
                        "35.160.177.10/32",
                        "34.216.18.129/32",
                        "3.216.235.48/32",
                        "34.231.96.243/32",
                        "44.199.3.254/32",
                        "174.129.205.191/32",
                        "44.199.127.226/32",
                        "44.199.45.64/32",
                        "3.221.151.112/32",
                        "52.205.184.192/32",
                        "52.72.137.240/32"
                    ]
                }
            }
        }
    ]
}

Wir werden unsere Deployments in Bitbucket Pipelines ausfuhren und diese IP-Adressen sind die ausgehenden IPs der Bitbucket Pipelines. Du kannst die Referenz unter https://support.atlassian.com/bitbucket-cloud/docs/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall/ einsehen.

CloudFront Cache Invalidation IAM Policy

Zum Ausfuhren des CloudFront Cache Invalidation-Befehls uber Bitbucket Pipelines kannst du die folgende IAM Policy verwenden. Du kannst die Policy demselben AWS-Benutzer zuweisen, der fur S3 Sync-Operationen berechtigt ist.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "CloudFrontCacheInvalidationPolicy",
            "Effect": "Allow",
            "Action": "cloudfront:CreateInvalidation",
            "Resource": "arn:aws:cloudfront::ACCOUNT_ID:distribution/CF_DISTRIBUTION_ID",
            "Condition": {
                "ForAnyValue:IpAddress": {
                    "aws:SourceIp": [
                        "34.199.54.113/32",
                        "34.232.25.90/32",
                        "34.232.119.183/32",
                        "34.236.25.177/32",
                        "35.171.175.212/32",
                        "52.54.90.98/32",
                        "52.202.195.162/32",
                        "52.203.14.55/32",
                        "52.204.96.37/32",
                        "34.218.156.209/32",
                        "34.218.168.212/32",
                        "52.41.219.63/32",
                        "35.155.178.254/32",
                        "35.160.177.10/32",
                        "34.216.18.129/32",
                        "3.216.235.48/32",
                        "34.231.96.243/32",
                        "44.199.3.254/32",
                        "174.129.205.191/32",
                        "44.199.127.226/32",
                        "44.199.45.64/32",
                        "3.221.151.112/32",
                        "52.205.184.192/32",
                        "52.72.137.240/32"

                ]
            }
        }
    }
]

}

Bitbucket Pipelines

Zuvor hast du bereits einen AWS-Benutzer fur die Ausfuhrung der Bitbucket Pipelines fur CI/CD-Operationen erstellt. Es ist an der Zeit, die Umgebungsvariablen im Repository zu setzen. AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY sind ausreichend.

Pipeline-Datei

Jetzt, in diesem Schritt, konnen wir eine bitbucket-pipelines.yml-Datei fur den S3 Sync und die CloudFront Cache Invalidation erstellen.

pipelines:
    branches:
      main:
        - step:
            name: Deploy to S3 Bucket
            deployment: Production
            script:
              - pipe: atlassian/aws-s3-deploy:1.1.0
                variables:
                  AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
                  AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
                  AWS_DEFAULT_REGION: AWS-REGION
                  S3_BUCKET: 'S3_BUCKET_NAME'
                  DELETE_FLAG: 'true'
                  LOCAL_PATH: './'
              - pipe: atlassian/aws-cloudfront-invalidate:0.1.1
                variables:
                  AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
                  AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
                  AWS_DEFAULT_REGION: AWS-REGION
                  DISTRIBUTION_ID: CLOUDFRONT-DIST-ID

Wenn der main-Branch einen neuen Commit hat, wird die Pipeline ausgelost und beginnt sofort zu laufen. Danach wird der Root-Pfad "/" deines Bitbucket-Repositorys mit deinem S3 Bucket synchronisiert und die Cache Invalidation sofort ausgefuhrt, um die neue Website auf alle Edge-Standorte zu ubertragen.

Ich hoffe, dieser Artikel hilft dir. Wenn du etwas fragen mochtest, hinterlasse einfach einen Kommentar. Ich werde so schnell wie moglich antworten.