11–20 of 84 posts
I feel like you don't need a deep dive for what you're describing. Start step by step. Before building on Github Actions, build locally. See if you can build and tag and image with the git SHA. Then run your automated test command against the image/container. Then see if you can write a github action doing exactly what you did locally. Random blog posts have been more helpful in my experience vs youtube videos.
It sounds to me like you have a project that involves on-demand deployment of containers. Like it or not, the current standard for that is kubernetes. As someone is already saying on here, there will still be Dockerfiles and container technology involved, but not necessarily "docker compose" or "docker swarm." Just my guess, but I think that's part of why you're struggling to find the tutorials you're looking for, is…
How did you gather this? OP only mentions CI/testing, nothing about deployment. That's a long distance from needing kubernetes.
1) your reverse proxy, Nginx/Caddy
2) your "app", or API, whatever. pick whatever you want, a Rails API, a Phoenix microservice, a Django monolithic app, whatever you want.
3) your database. Postgres, whatever
4) Redis - not just for caching. Can use it for anything that requires some level of persistence, or any message bus needs. They even have some plugins you can use (iirc, limited to enterprise plans... maybe?) like RedisGraph.
5) elasticsearch, if you need real-time indexing and search capabilities. Alternatively you can just spin up a dedicated API that leverages full text search for your database container from 3)
6) ??? (sky is the limit!)
I prefer docker compose to Kubernetes because I am not a megacorp. You just define your different services, let them run, expose the right ports, and then things should "just work"
Sometimes you need to specifically name your containers (like naming redis container `redis`, and then in your code you will have to use `redis` as the hostname instead of `localhost` for example).
basically That's It (tm)
Earlier quoted context omitted.
> With Docker shim removed from kubernetes no one is using Docker professionally. I think this statement is not as precise as it should be. I'm running docker produced images in a k8s cluster and had to google what you are talking about here. https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-... "Docker-produced images will continue to work in your cluster with all runtimes, as they always have." Dockerfile…
To disambiguate it’s necessary to separate Docker the runtime from OCI image format, commonly still referred to by a lot of people colloquially as “Docker Images”. Docker the desktop software, file format and CLI is still very much used professionally to build and test OCI images, which then run in Kubernetes. Docker as a container runtime platform (and orchestration with Swarm) is what is generally going out of vogu…
Docker starts to become super useful when you have an application you are deploying that has a few `service` dependencies. Typical deployments include something like 1) your reverse proxy, Nginx/Caddy 2) your "app", or API, whatever. pick whatever you want, a Rails API, a Phoenix microservice, a Django monolithic app, whatever you want. 3) your database. Postgres, whatever 4) Redis - not just for caching. Can use it…
In which cases would you prefer Kubernetes? Or rather, why would a megacorp prefer it over standard Docker?
Docker starts to become super useful when you have an application you are deploying that has a few `service` dependencies. Typical deployments include something like 1) your reverse proxy, Nginx/Caddy 2) your "app", or API, whatever. pick whatever you want, a Rails API, a Phoenix microservice, a Django monolithic app, whatever you want. 3) your database. Postgres, whatever 4) Redis - not just for caching. Can use it…
> I prefer docker compose to Kubernetes because I am not a megacorp. In which cases would you prefer Kubernetes? Or rather, why would a megacorp prefer it over standard Docker?
Docker starts to become super useful when you have an application you are deploying that has a few `service` dependencies. Typical deployments include something like 1) your reverse proxy, Nginx/Caddy 2) your "app", or API, whatever. pick whatever you want, a Rails API, a Phoenix microservice, a Django monolithic app, whatever you want. 3) your database. Postgres, whatever 4) Redis - not just for caching. Can use it…
> I prefer docker compose to Kubernetes because I am not a megacorp. In which cases would you prefer Kubernetes? Or rather, why would a megacorp prefer it over standard Docker?
"Docker compose" (not the same thing as docker) works great at single machine scale/local development environments, but isn't really designed to scale much beyond this to production environments, multiple servers and data centers etc, which Kubernetes is. This isn't to say you couldn't deploy something to production with compose, its just not very likely outside of small personal projects - there are heaps of features in Kubernetes that simply don't exist in compose.
Generally you'd typically find a docker compose configuration for easy local development environment deployments, a Kubernetes configuration for managing the production environments, although there are no hard and fast rules here. Compose generally works best where the services fit all on the same box, which is rare for a business of almost any size in production, but common for local dev work.
I also prefer Compose for personal projects and local development, but it simply wouldn't work at any place I've worked for production deployments.
Earlier quoted context omitted.
> I prefer docker compose to Kubernetes because I am not a megacorp. In which cases would you prefer Kubernetes? Or rather, why would a megacorp prefer it over standard Docker?
Kubernetes and docker solve different problems. One is a container runtime, the other is a container orchestration tool. A mega-corp using Kubernetes can still use Docker, the two can work together. "Docker compose" (not the same thing as docker) works great at single machine scale/local development environments, but isn't really designed to scale much beyond this to production environments, multiple servers and data…
Earlier quoted context omitted.
> I prefer docker compose to Kubernetes because I am not a megacorp. In which cases would you prefer Kubernetes? Or rather, why would a megacorp prefer it over standard Docker?
Kubernetes and docker solve different problems. One is a container runtime, the other is a container orchestration tool. A mega-corp using Kubernetes can still use Docker, the two can work together. "Docker compose" (not the same thing as docker) works great at single machine scale/local development environments, but isn't really designed to scale much beyond this to production environments, multiple servers and data…