Sirvick DevOps Diary

Let's pause a bit and look at the business aspect of my docker ECR failure, and why every business in Nigeria needs automation. Day 12. Yesterday  Day 11, I spent 4 hours with fuel on, trying to push my Docker images to AWS ECR. GitHub Actions kept saying denied: authorization token expired. I was angry at AWS. But this morning I realized something; this error taught me a pure business lesson that every POS business, barber shop, and online vendor in PH, Lagos and every other cities in Nigeria needs. Let me connect it for you in a relatable language: My project is Netflix clone. I have backend (Node.js) and frontend (React). Each is inside Docker container, like two different shops. I wanted GitHub Actions to automatically deliver those shops to AWS ECR (my warehouse), then my EC2 server will sell them to customers. But I had two hidden problems: Nested.git inside netflix_backend — I copied code from another laptop, and it came with its own .git.  So, inside my main business, ...

 I'm Uko M. Joseph aka SirVick, writing from Port Harcourt. Day 11 of my 30-day DevOps challenge. My project is a full Netflix clone: netflix_backend (Node.js API) and netflix_frontend (React). Code is on GitHub at netflix project folder. Goal is automatic deployment: every time I push to main branch, GitHub Actions should build Docker images and push to AWS ECR in us-east-1, then my EC2 server at sirvickcloud9.online pulls and runs them. I set up .github/workflows/cicd.yaml with a job called build-and-push. Workflow looked fine in VS Code, but in GitHub Actions log, it failed at Step 4: Docker push. The log showed: denied: Your authorization token has expired OR failed to push 4144...dkr.ecr.us-east-1.amazonaws.com/netflix_frontend:latest I spent 4 hours debugging with fuel running. My folder structure that caused problem:  netflix project/   .git (main repo)   netflix_backend/     .git (old nested - DELETE THIS)     Dockerfile   netflix_fr...

For 9 days I have been sharing NGold — my Netflix clone — on an IP address. Yesterday someone on Instagram asked me: "SirVick, do you actually know networking or just docker run?"  That question hit me. Because he was right. Sharing 32.196.145.76:3000 is not        DevOps. It is just running a container. So I stopped everything and built what you now see at sirvickcloud9.online . This is not a template portfolio. This is infrastructure. If you open the site today you will see three sections I built:  Top hero says "Building Reliable Systems — DevOps & Cloud Solutions. I'm Uko Sirvick, an entry-level Cloud, DevOps and System Administration professional learning by building practical infrastructure, automation and deployment projects."  Second section says "Turning ideas into scalable infrastructure. I enjoy solving technical problems, learning cloud technologies and building systems that are secure, reliable and easier to maintain. My current focus ...

  I built my VPC. I was proud. VPC 10.0.0.0/16 as fenced compound in Port Harcourt, Public Subnet 10.0.1.0/24 as visitor's parlor, Private Subnet 10.0.2.0/24 as inner room where my database sleeps. I thought I was done. Then I checked AWS GuardDuty. Red alert: `Unprotected port 22 open to internet`. My EC2 SSH was open to `0.0.0.0/0`. Anybody in the world could brute-force my server. That's when I learned: VPC and Subnet are just walls. *Route Table and Security Group are the doors and gate men.* Without them, your house is open. Let me break it down the way I finally understood it after 3 YouTube videos and 2 failed labs. Route Table — The Road Sign (Where Traffic GOES) Imagine you are in Mile 3 Park. Buses shouting destinations. Without road signs, you enter wrong bus. Every subnet in AWS MUST be associated to a Route Table. If not, it uses Main Route Table — which is confusion. Public Route Table — NGold-Public-RT Destination |   Target | Meaning 10.0.0.0/16 |  ...