Bitbucket e um produto da Atlassian e um armazenamento de codigo baseado em Git e ferramentas de CI/CD otimizadas para equipes de colaboracao que usam Jira. Quando voce altera seu codigo e mantem revisoes e historico no Bitbucket, voce tambem precisa de alguma automacao para implantacao.

CI/CD serve para toda automacao e significa Continuous Integration e Continuous Delivery. Neste artigo, vamos usar CI e CD ao mesmo tempo.

Vou pular "Como usar o Bitbucket?" e apresentarei a voce os Bitbucket Pipelines para implantacao continua no AWS S3 usando CloudFront para distribuicao em todo o mundo.

Quando voce cria um bucket S3 com suporte a hospedagem estatica, voce deve sincronizar da sua pasta local para o bucket S3. Normalmente, devemos executar o comando aws s3 sync PASTA_LOCAL/ s3://NOME_DO_BUCKET_COM_HOSTING_ESTATICO --delete para sincronizar 100% da pasta local com o Bucket S3.

Se voce esta usando CloudFront para distribuicao, vera o conteudo antigo ao visitar o site. A razao e que o CloudFront armazena em cache todo o conteudo em todas as edge locations e serve o conteudo das edge locations. Devemos "invalidar o cache" para o novo conteudo e precisamos re-armazenar em cache nas edge locations.

Qual Politica IAM para S3 e CloudFront usar?

Para maxima seguranca, eu realmente gosto de colocar maxima restricao e minima permissao nas Politicas IAM. Voce pode ver as politicas abaixo:

Politica IAM para Bucket S3

{
    "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"
                    ]
                }
            }
        }
    ]
}

Vamos executar nossos deploys nos Bitbucket Pipelines e estes enderecos IP sao os IPs de saida dos Bitbucket Pipelines. Voce pode ver a referencia em https://support.atlassian.com/bitbucket-cloud/docs/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall/

Politica IAM para Cache Invalidation do CloudFront

Para executar o comando de invalidacao de cache do CloudFront via Bitbucket Pipelines, voce pode usar a Politica IAM abaixo. Voce pode anexar a politica ao mesmo usuario AWS que tem permissao para operacoes de S3 Sync.

{
    "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

Anteriormente, voce ja criou um usuario AWS para executar os Bitbucket Pipelines para operacoes de CI/CD. Agora e hora de colocar as variaveis de ambiente no repositorio. AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY sao suficientes.

Arquivo Pipeline

Agora, neste passo, podemos criar um arquivo bitbucket-pipelines.yml para executar o S3 Sync e CloudFront Cache Invalidation.

pipelines:
    branches:
      main:
        - step:
            name: Deploy para Bucket S3
            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

Quando o branch main tiver um novo commit, o pipeline sera acionado e comecara a executar imediatamente. Depois disso, o caminho raiz "/" do seu Repositorio Bitbucket sera sincronizado com seu Bucket S3 e executara a invalidacao de cache imediatamente para aplicar o novo site a todas as edge locations.

Espero que este artigo ajude voce. Se quiser perguntar algo, basta deixar um comentario. Retornarei a voce o mais rapido que puder.