i am not a devops engineer. i appreciate any critique or correction.
Deploying Nextcloud on AWS ECS with Pulumi
This Pulumi programme deploys a highly-available, cost-effective Nextcloud service on AWS Fargate with a serverless Aurora PostgreSQL database.
Deployment Option 1 (GitOps)
The first few items are high-level instructions only. You can follow the instructions from the hyperlinked web pages. They include the best practices as recommended by the authors.
- A Pulumi account. This is for creating a Personal Access Token that is required when provisioning the AWS resources.
- Create a non-root AWS IAM User called
pulumi-user
. - Create an IAM User Group called
pulumi-group
- Add the
pulumi-user
to thepulumi-group
User Group. - Attach the
IAMFullAccess
policy topulumi-group
. TheIAMFullAccess
allows your IAM User to add the remaining required IAM policies to the IAM User Group using the automation script later. - Create an access key for your non-root IAM User.
- On your Pulumi account, go to Personal access tokens and create a token.
- Also create a password for the Aurora Database. You can use a password generator.
- Clone this repository either to your GitLab or GitHub.
- This works either on GitLab CI/CD or GitHub Actions. On GitLab, go to the cloned repository settings > Settings > Variables. On GitHub, go to the cloned repository settings > Secrets and variables > Actions > Secrets.
- Store the credentials from steps 6-8 as
AWS_ACCESS_KEY_ID
,AWS_SECRET_ACCESS_KEY
,PULUMI_ACCESS_TOKEN
, andPOSTGRES_PASSWORD
. These will be used as environment variables by the deployment script. - On AWS Console, go to EC2 > Load Balancers. The
DNS name
is where you access the Nextcloud Web Interface to establish your administrative credentials.
[!NOTE] The automatic deployment will be triggered if there are changes made on the
main.go
,.gitlab-ci.yml
, or theci.yml
file upon doing agit push
. Onmain.go
, you can adjust the specifications of the resources to be manifested. Notable ones are in lines 327, 328, 571, 572, 602, 603, 640.
Deployment Option 2 (Manual)
- Install Go, AWS CLI, and Pulumi.
- Follow steps 1-8 above.
- Add the required IAM policies to the IAM User Group to allow Pulumi to interact with AWS resources:
printf '%s\n' "arn:aws:iam::aws:policy/AmazonS3FullAccess" "arn:aws:iam::aws:policy/AmazonECS_FullAccess" "arn:aws:iam::aws:policy/ElasticLoadBalancingFullAccess" "arn:aws:iam::aws:policy/CloudWatchEventsFullAccess" "arn:aws:iam::aws:policy/AmazonEC2FullAccess" "arn:aws:iam::aws:policy/AmazonVPCFullAccess" "arn:aws:iam::aws:policy/SecretsManagerReadWrite" "arn:aws:iam::aws:policy/AmazonElasticFileSystemFullAccess" "arn:aws:iam::aws:policy/AmazonRDSFullAccess" | xargs -I {} aws iam attach-group-policy --group-name pulumi-group --policy-arn {}
- Add the environment variables.
export PULUMI_ACCESS_TOKEN="value" && export AWS_ACCESS_KEY_ID="value" && export AWS_SECRET_ACCESS_KEY="value" && export POSTGRES_PASSWORD="value"
- Clone the repository locally and deploy.
mkdir pulumi-aws && \
cd pulumi-aws && \
pulumi new aws-go && \
rm * && \
git clone https://gitlab.com/joevizcara/pulumi-aws.git . && \
pulumi up
Deprovisioning
pulumi destroy --yes
Local Testing
The Pulumi.aws-go-dev.yaml
file contains a code block to use with Localstack for local testing.
Features
- Subscription-free application - Nextcloud is a free and open-source cloud storage and file-sharing platform.
- Serverless management - using Fargate and Aurora Serverless reduces infrastructure management.
- Reduced cost - can be scaled and as highly available as an AWS EKS cluster, but with cost lower per-hour.
- Go coding language - a popular language for cloud-native applications, eliminating syntax barriers for engineers.
In that case, Pulumi permissions are too broad IMHO for what it has to do, an enterprise should adhere to least privilege. Likewise, as I wrote in another comment, the egress security groups are unclear to me (why any traffic at all is needed?) and the image consumed should be pinned to a digest. Or better yet, should be coming from a private enterprise registry, ideally with an attestation that can be verified at runtime.
I am not sure ECS Fargate makes sense vs an ec2 instance to run the workload. This setup alone will cost about $30/month assuming half a vCPU per replica with Fargate, plus about $12 for the memory (1GB/task). 2xt2.micro could be run for ~$20 without even considering reservation discounts etc. Obviously the gap will become even larger at scale, which I suppose might be very interesting for an enterprise.