Introduction Designing a mobile app today goes far beyond building a beautiful interface. Native apps — whether for iOS or Android — need secure authentication, user role management, real-time communication with the backend, and scalable infrastructure to support growth. In this post, I’ll walk you through a clean and modern architecture to connect native mobile apps to a robust backend on AWS. The architecture is modular, scalable, and aligned with best practices for security and performance — without relying on overly complex tools. Why it matters: apps today are more than just UI A production-grade mobile app often includes: User login (email, Google, or others), Differentiated access for multiple roles (e.g., user vs admin), Secure token-based communication, A backend capable of handling business logic and data, Data storage, asset management, and scalable APIs, Compliance with Google Play and App Store requirements. All of these require a backend architecture ...
This is a small article about understanding the liveness, readiness and startup in kubernetes.
There's good explanation in the kubernetes documentation: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
This video also explains well the process: https://www.youtube.com/watch?v=aTlQBofihJQ
But I wanted to understand it in a practical way.
So I have this demo: https://github.com/DiegoTc/guest-book-js-docker/tree/Running-App-Version-1
It's a simple application running on a kubernetes cluster.
https://github.com/DiegoTc/guest-book-js-docker/blob/Running-App-Version-1/argo/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: chat-ui
spec:
replicas: 1
revisionHistoryLimit: 3
selector:
matchLabels:
app: chat-ui
template:
metadata:
labels:
app: chat-ui
spec:
containers:
- image: diegotc/guestbook:20230803-064434
imagePullPolicy: Always
name: chat-ui
ports:
- containerPort: 5500
Everything is OK. You can see how it appears in our ArgoCD
Repo with failing image: https://github.com/DiegoTc/guest-book-js-docker/tree/Crash-App-Version-1
Docker image working: diegotc/guestbook:20230803-064434
But what happens, if we deploy an image that crashes?
Docker images crashes: diegotc/guestbook:20230803-070920
So what happens, is that our application is in a infinite loop, trying to start and it doesn't works.
So now, we're going to see the same example, but with the startup configuration.
Repo with solution: https://github.com/DiegoTc/guest-book-js-docker/blob/Running-App-Version-2/argo/deployment.yaml
Docker image working: diegotc/guestbook:20230803-073811
After we deploy our application that will cause the crash
Repo: https://github.com/DiegoTc/guest-book-js-docker/tree/Crash-App-Version-2Docker images crashes: diegotc/guestbook:20230803-082315
As you can see, our application is still running, even we deploy a wrong image.
You can read more about it in the kubernete documentation: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
Comentarios
Publicar un comentario