AWS EKS DevOps - Lab application deployment

Cliente Freelancer · Remoto · Remoto · freelance · mid · 30–250 USD

Publicada el 2026-07-29

Descripción de la oferta

A DevOps exercise that need to be Lab tested and run smoothy. Time to get it done should be between 4-9 hours depends on you. The Application • A LiveView application (Provided in a Zip file) page that holds long-lived WebSocket connections. • Latency-sensitive. Bursty traffic with sharp peaks; must stay responsive under load. • CPU and memory only — no GPU, no specialized hardware. • Backed by PostgreSQL. You may assume the database is provided externally (RDS) and only need to wire connectivity. • Cannot tolerate sudden node loss without graceful draining — open LiveView sockets should not be dropped abruptly during a deploy or scale-down. Deliverables: Submit a zip fole containing the following: 1. Dockerfile • A Dockerfile that produces a production image for the Phoenix application. • I expect a multi-stage build, a non-root runtime user, a minimal runtime base, and no secrets baked into layers. • How you produce the production artifact — and what runs as PID 1 inside the container — is a decision we want you to make and justify. 2. Kubernetes manifests Helm chart or Kustomize overlays — your choice. Include at minimum: • Deployment with appropriate replicas, probes, resource requests and limits, security context, and graceful shutdown configuration. • Service of the appropriate type (consider what LiveView needs to function correctly). • HorizontalPodAutoscaler with scaling logic that fits the workload. Justify your choice of scaling signal. • PodDisruptionBudget tuned to the application’s tolerance for disruption — keeping in mind that LiveView holds long-lived connections. • ServiceAccount and any RBAC the workload actually needs. • Any additional resources you decide are warranted (we leave this open intentionally). 3. Karpenter configuration Provide NodePool and EC2NodeClass specs for this workload. We expect to see deliberate choices about: • Instance families and sizes, with reasoning. • Capacity type strategy — on-demand, spot, or a weighted mix — and why that fits a connection-holding workload. • Consolidation policy and how it interacts with the application’s disruption tolerance. • Any taints, tolerations, or affinity that you find warranted. 4. README A README.md that explains your design. We read this carefully. Cover: • How the production artifact is built and what runs inside the container. • How a deploy or scale-down does not abruptly kill open WebSocket connections. • Your choice of HPA signal and why CPU alone is or is not the right one here. • Whether you addressed running the application as more than one replica, and what implications that has for the application itself. If you deferred this, say so and explain. • Why you chose the instance families and capacity types you did. • GovCloud-specific considerations you accounted for or would account for in production. • What you would add for production that you intentionally left out, and why. • Anything you would do differently with more time. 5. Discovery log A short section in the README (5 to 10 bullets is plenty) capturing what you did not know coming into this assignment and how you figured it out. We want to see what you learned, what surprised you, what you chose to investigate deeply, and what you chose to take on faith. This is not a test of how little you can admit not knowing — the most useful submissions are honest about both. 6. Optional bonus • A short load-test plan, or a working load test, demonstrating scaling behavior under bursty traffic. • A custom-metrics HPA sketch using a signal more meaningful than CPU. • A working multi-replica setup with the cross-pod implications addressed end-to-end. Bonus items are genuinely optional. A strong core submission beats a sprawling one with bonuses. Constraints and Assumptions • Target environment is AWS GovCloud (us-gov-west-1). You do not need to actually deploy there; assume it as the target when making design choices. • You do not need a live EKS cluster. Local kind or k3d is sufficient to verify that manifests apply cleanly. Karpenter specs are evaluated as code, not by running them. • You may use any tools you would normally use, including AI assistants and documentation. We will discuss your choices in the walkthrough, so be ready to defend them as your own. • Prior Elixir or Phoenix experience is not expected. If you have it, great. If you do not, that is the point — show us how you operate.

Skills

Fuente original: freelancer

Análisis JobHunter