Browsed https://github.com/actions/checkout/releases to check which version I should use in my GitHub Actions configuration YAML. Updated v3 -> v4 because there is no reason not to. The latest does not introduce breaking changes, and it provides bug fixes and additional features.
I suddenly began wondering what would happen if online documentation was unavailable for organizational issues or other reasons. I used to see people publish books about programming language manuals, but now, for example, if servers are down, I cannot check the documentation.
In that case, I may be able to check the way back machine. I also bet someone will host a website to serve the documents voluntarily. Maybe I was worried too much.
Browsed What is Amazon EKS? - Amazon EKS
It's embarassing that I have little knowledge on Kubernetes. I'm not a DevOps engineer with my full-time position, and also other projects I touched are better off sticking to simple architecture. (All my friends at BigTech also don't understand how it works, so it's not that embarrasing I don't know how to scale it, I hope?)
I hear that AWS and Azure have very different policy for server outage; Azure provides more flexible compensation, but I don't know much about it.
Stack Overflow: What’s the difference between Docker Compose and Kubernetes?
Docker Compose deploys multi-container Docker apps to a single server, while Kubernetes is a production-grade container orchestrator that can run multiple container runtimes, including Docker's, across multiple virtual or physical machines.
So they are very different.
I cannot use my compose.yaml
Kompose (The website looks neat)
An official Kubernetes project, located at github.com/kubernetes/kompose
GO FROM DOCKER COMPOSE TO KUBERNETES
Kompose is a conversion tool for Docker Compose to container orchestrators such as Kubernetes (or OpenShift).
I might want to use Kompose if I need to use configure Kubernetes with a Compose file.
How Compose works | Docker Docs
The default path for a Compose file is compose.yaml (preferred) or compose.yml that is placed in the working directory. Compose also supports docker-compose.yaml and docker-compose.yml for backwards compatibility of earlier versions. If both files exist, Compose prefers the canonical compose.yaml.
Projects I've been involved use docker-compose.yml, so I
was surprised to know compose.yaml is the preferred name
here. I will use compose.yaml whenever possible from now
on.
Version and name top-level elements
Also, I see that the top-level version property in a
Compose file is now obsolete while I can see that in several
projects.
The top-level version property is defined by the Compose Specification for backward compatibility. It is only informative and you’ll receive a warning message that it is obsolete if used. Compose doesn’t use version to select an exact schema to validate the Compose file, but prefers the most recent schema when it’s implemented.
Sushi bowl 800 Avocado 200 Yogurt 300
Total 1300 kcal
TODO: