Devops

Creating scripts are easy. But creating a small docker image is not 😅. Not all Linux flavors are created equal, some are bigger than others, etc. But this difference is very crucial when it comes to reducing docker image size. A simple bash script docker image Given a Dockerfile (change apk to apt for ubuntu): FROM alpine:3 WORKDIR /app RUN apk update && apk add jq curl COPY water-cut-notify.sh ./ ENTRYPOINT ["sh", "/app/water-cut-notify.sh"] Base image Docker image size alpine 11.1MB ubuntu 122MB Ubuntu image size is 1099% larger!!!!!! ...

Correction 2023-07-06: I only recently realized SSM and Secrets Manager are not the same. At my organization we use sops to check in encrypted secrets into git repos. This solves plaintext credentials in version control. However, say, you have 5 repos using the same database credentials, rotating secrets means you have to go into each repo and update the SOPS credentials manually. Also worth nothing that, for GitHub actions, authenticating AWS means you have to add repo secrets. This means for all the repos you have CI enabled, you have to populate the repo secrets with AWS credentials. When time comes for rotating the creds, you’ll encounter the same situation as above. ...

Update 2021-11-29 Recently we create more PRs, notice that there are a lot of redundant steps (env setup before triggering checks, etc). Found out you can cache steps in GitHub Actions, so I did some research. Got it working and turns out I reduce at least 60% actions time for a large docker image build (since only the later RUN directives are changed more frequently). For pipenv it shaved off 1 minute 18 seconds. Pretty neat! ...

ecs-cli configure profile \ --access-key $KEY \ --secret-key $SECRET \ --profile-name $PROFILE ### launch mode: fargate ecs-cli configure \ --cluster $CLUSTER \ --default-launch-type FARGATE \ --config-name $NAME \ --region ap-southeast-1 ecs-cli up \ --cluster-config $NAME \ --vpc $VPCID\ --subnets $SUBNETID1, $SUBNETID2 ### launch mode: ec2 ecs-cli configure \ --cluster $CLUSTER \ --region ap-southeast-1 \ --default-launch-type EC2 \ --config-name $NAME ecs-cli up --keypair $KEYPAIR \ --extra-user-data userData.sh \ --capability-iam --size 1 \ --instance-type t2.large \ --cluster-config $NAME \ --verbose \ --force \ --aws-profile $PROFILE ecs-cli compose \ --cluster-config $NAME \ --file docker-compose.yml up \ --create-log-groups

Self-hosting is a practice for running and managing websites / services using your own server. Some people do this because they are concerned about their privacy, or some services are free if they host it themselves. Below are instructions for how to do self-hosting (also applies to hosting your own website too). Requirements Domain name Server (can be your own computer at home or VPS) Instructions Set up and secure the server (set up password, disable password login (which means you can only login via SSH key), etc.) Deploy a website on your server (follow instructions for each service. I recommend deploy via Docker). If you are using a server at home which has dynamic IP, setup DDNS (I recommend duckdns.org, since it has very fast TTL). Go to your domain name registrar, under DNS, add a CNAME record for your desired subdomain, and set the value to your duckdns.org domain. On your server, install a webserver for reverse-proxy. I recommend nginx or Caddy. Create a virtual host config for your website in your webserver of choice. On your router configuration page, under port forwarding, create two entries for port 80 and 443. Wait for a few minutes for the DNS to be updated, and you should be able to access your website from the specified domain. As for actual implementation, I suggest you read a few articles for each step, so you can get the overall idea of what’s to be done. Generally, the common steps should be the same across all articles, since that’s the “baseline” for each process. ...