DOCSEARCHbyAlgolia
Submit Docs

DevOps Chronicles Documentation

website·Indexed 31 days ago

https://devopschronicles.com/

A comprehensive resource for DevOps engineering, featuring courses on AWS cloud infrastructure, virtualization architecture with VirtualBox, and observability foundations. The site provides decision frameworks for AWS services (EC2 vs Lambda vs ECS, RDS vs Aurora vs DynamoDB), incident post-mortems covering the Linux OOM Killer and disk full scenarios, and production-style project guides like the FinPay API.

Tokens
23.9K
Snippets
128
Records
186
Agent score
50%

What's inside DevOps Chronicles

  1. Overview of FinPay API Payment Platform

    FinPay API is a production-style payment platform built using Node.js, PostgreSQL, and Redis. It implements critical financial system features including Stripe-inspired idempotency to prevent duplicate transactions, atomic transfers to ensure data consistency, and multi-tier rate limiting to protect API availability.

  2. Overview of FinPay API Payment Platform

    FinPay API is a production-style payment platform built using Node.js, PostgreSQL, and Redis. It implements high-reliability financial features including Stripe-inspired idempotency, atomic transfers, and multi-tier rate limiting.

  3. Overview of FinPay API Payment Platform

    FinPay API is a production-style payment platform built using Node.js, PostgreSQL, and Redis. It implements high-reliability financial features including Stripe-inspired idempotency, atomic transfers, and multi-tier rate limiting.

  4. Overview of FinPay API Payment Platform

    FinPay API is a production-style payment platform built using Node.js, PostgreSQL, and Redis. It implements high-reliability financial features including Stripe-inspired idempotency, atomic transfers, and multi-tier rate limiting.

  5. Set up a basic two-node distributed lab architecture

    Follow these steps to establish a separated application and database environment:

    1. Clone a hardened base image to create app-node-01 and db-node-01.
    2. Configure network adapters: app-node-01 requires both NAT and Host-Only; db-node-01 should use Host-Only only to ensure it is not reachable from outside the lab.
    3. Set hostnames and update /etc/hosts on both nodes for internal resolution.
    4. Install Nginx on the application node.
    5. Install MariaDB on the database node, binding it specifically to the host-only IP address.
    6. Validate that nodes can ping each other over the host-only network.

  6. Use Grafana Alloy for Prometheus metrics collection

    Grafana Alloy is a lightweight metrics agent that scrapes a /metrics endpoint and pushes data to Grafana Cloud. It is preferred over direct pushes (e.g., via axios) because Grafana Cloud's remote write endpoint requires the Prometheus protobuf format rather than plain text, and Alloy automatically handles network issues such as IPv6 connection timeouts.

  7. Design a three-tier security group and IAM architecture

    For a standard three-tier application, implement the following segmentation and role strategy:

    Security Group Design

    • Load Balancer Group: Inbound HTTP/HTTPS from internet $\rightarrow$ Outbound to App Group.
    • App Tier Group: Inbound from Load Balancer Group only $\rightarrow$ Outbound to Database Group.
    • Database Group: Inbound from App Group only $\rightarrow$ No outbound internet.

    IAM Role Design

    • Application Runtime Role: Minimum permissions required for the app to function.
    • Deployment Role: Permissions for CodePipeline/CodeDeploy only.
    • Monitoring Role: Read-only CloudWatch and EC2 describe permissions.

  8. Avoid common AWS scaling mistakes

    When designing scaling architecture, avoid these common pitfalls to prevent outages and unnecessary costs:

    • Scaling only vertically: Leaves a single point of failure.
    • Missing health checks: Failed instances continue to receive traffic.
    • Minimum 1 instance in ASG: A single instance failure causes an outage during the replacement window.
    • Aggressive scale-in: Instances may terminate before long-running requests complete.
    • No scale-in protection: Connections may be dropped mid-request during draining.
    • Thresholds set too low: Leads to 'thrashing' (constant scaling up/down) and excessive costs.
    • Lack of monitoring: Prevents the ability to validate or tune scaling policies.

  9. Implement Declarative Infrastructure with Terraform

    Terraform uses a declarative approach to Infrastructure as Code (IaC). Instead of writing a script of steps to take, you define the 'desired state' of your infrastructure. Terraform then compares this desired state against the 'current state' of the cloud environment and reconciles the differences to ensure reality matches the code.
    resource "aws_instance" "app" {
  instance_type = "t3.micro"
  subnet_id     = var.private_subnet_id
}

  10. Design Security Groups by role for scalable architecture

    Instead of hardcoding IP addresses, design security groups by architectural tier (role). Reference the security group ID as the source/destination in rules. This ensures that when Auto Scaling launches new instances, they automatically inherit the correct permissions without manual rule updates. This creates a tiered defense where the database tier has no direct internet exposure.
    - sg-loadbalancer: Inbound (80/443 from 0.0.0.0/0) -> Outbound (8080 to sg-app)
- sg-app: Inbound (8080 from sg-loadbalancer) -> Outbound (5432 to sg-database)
- sg-database: Inbound (5432 from sg-app) -> Outbound (None)

  11. Centralized Observability Toolstack Overview

    While manual inspection (SSH and CLI) is the foundation, production environments require centralized tools to scale observability. The following stack is used to move from manual to automated monitoring:
    ToolPurpose
    PrometheusScrapes and stores metrics from all nodes automatically
    GrafanaVisualizes metrics on dashboards
    LokiCentralizes logs from all nodes
    AlertmanagerSends notifications when thresholds are breached
    node_exporterExposes Linux system metrics to Prometheus

  12. Implement a Standard Multi-AZ VPC Architecture

    A standard production-ready VPC design should include the following components to ensure segmentation and availability across two Availability Zones (AZs):

    1. CIDR Block: Use a /16 block (e.g., 10.0.0.0/16) to allow for growth.
    2. Public Subnets: Two subnets (one per AZ) for internet-facing resources.
    3. Private App Subnets: Two subnets (one per AZ) for application servers.
    4. Private Database Subnets: Two subnets (one per AZ) for data stores (these should have no direct route to 0.0.0.0/0).
    5. Connectivity:
      • An Internet Gateway (IGW) attached to the VPC for public traffic.
      • A NAT Gateway located in a public subnet to allow private instances to reach the internet.
    6. Routing: Three distinct route tables for Public, Private App, and Private DB tiers.