Sirvick DevOps Diary

 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 |  ...

Day 8: I Was Deploying Wrong — What Subnet, Internet Gateway & NAT Gateway Taught Me About My NGold Attack People asked me yesterday after my AWS attack alert: "SirVick, do you even know subnet, Internet Gateway, NAT Gateway?" I laughed because 2 days ago I didn't. I just clicked "Launch EC2" and thought AWS does networking automatically. After my instance at 32.196.145.76:3000 was scanned, I finally sat down to learn VPC networking. And I realized I was deploying wrong from Day 1. Let me explain networking like I explained Docker with garri and cooler — Port Harcourt style, so you never forget. VPC = Your Fenced Family Compound VPC (Virtual Private Cloud) is like your family compound in PH. When you create AWS account, AWS gives you default VPC — like government giving you land with fence already built. Inside that fence, you can build houses (subnets), you have main gate (Internet Gateway). Without fence, your house is on the road — anyone enters....

Day 7: Bash Scripting Saved Me — How I Automated NGold Deployment After AWS Attack Alert on My EC2 Yesterday was supposed to be just another Linux day. I woke up early in Port Harcourt, ready to write about file permissions and processes for Day 6. My Netflix Clone NGold was live and happy at 32.196.145.76:3000. I had just pushed a new build, Docker was running, and I was feeling like a real DevOps engineer. Then at 9:12 PM, my phone buzzed. AWS email: "Your Amazon EC2 instance has been identified as being targeted for penetration attempts." My heart cut instantly. I opened the email with shaky hands. AWS GuardDuty was flagging my t2.micro instance. Someone, or some bot, was scanning my IP from different locations. The report mentioned SSH brute force attempts and suspicious port probing. I have never felt that kind of panic in this 7-day journey. I spent 6 days building, now is my project about to become someone's crypto mining machine? I did what every junior De...

After I deployed my Netflix Clone NGold to AWS EC2 on Day 2, I honestly thought the hard part was over. From Port Harcourt, fighting git push errors, to finally seeing my app live on 32.196.145.76:3000, I felt like a Cloud Engineer already. I was wrong. The real DevOps journey started the moment I SSHed into that black terminal screen. AWS EC2 gives you a virtual computer, but Linux is the operating system that powers it. Without understanding the Linux environment, your Cloud deployment will not survive one day in production. Docker, AWS, Kubernetes — all of them run ON Linux. That was my Day 6 lesson. 1. The Linux File System – Where Everything Actually Lives Unlike Windows with C: and D: drives, Linux has a single tree starting from root (/). This confused me at first. Where is my app? Where are logs? I learned: /home/ubuntu is where my NGold code lives, /var/log is where all error logs hide (this saved me when my container crashed), /etc holds all system configs, and /tmp is ...