NFS is a commonly used storage option for Kubernetes, but it is not as reliable as some other options such as persistent volumes or distributed file systems. This is because NFS relies on a single server for storage, which can be a single point of failure. Additionally, NFS can experience performance degradation when handling high volumes of data or a large number of concurrent connections.

I can't tell exactly what you are trying, it looks like you might just not have Traefik and the services on the same network. Its also helpful to have a domain that's going to resolve to 127.0.0.1 on wildcard queries. This might be a valuable starting point as a working example. networks: traefik: name: demo_traefik services: proxy: image: traefik:latest command: > --accesslog=true --api.insecure=true --log.level=DEBUG --providers.docker=true --providers.docker.network=demo_traefik ports: - "80:80" - "8080:8080" networks: - traefik volumes: - /var/run/docker.sock:/var/run/docker.sock labels: traefik.http.routers.demo_traefik.rule: Host(traefik.localtest.me) traefik.http.services.demo_traefik.loadbalancer.server.port: 8080 example: image: nginx networks: - traefik scale: 4 labels: traefik.http.routers.demo_nginx.rule: Host(example.localtest.me) traefik.http.services.demo_nginx.loadbalancer.server.port: 80 whoami: image: traefik/whoami networks: - traefik labels: traefik.http.middlewares.whoami_strip.stripprefix.prefixes: /whoami traefik.http.routers.whoami.rule: Host(example.localtest.me) && PathPrefix(/whoami) traefik.http.routers.whoami.middlewares: whoami_strip docker compose up and then visit http://example.localtest.me/whoami in your browser.

Apparently rootless mode runs Docker only when a user session starts. After stopping the session, Docker stops too. I had to enable lingering: https://stackoverflow.com/questions/73299883/docker-containers-terminate-on-shell-logout $ loginctl enable-linger $UID

Your ip show does mention 10.42.0.0/32, 10.42.0.200/32. No traces of 10.42.0.232, though. From LAN/outside SDN: can you connect any TCP port, or ping that address? anything that answers? I suspect nothing would. In addition to that Traefik rule, you mentioned creating a Service ... Are you sure you did it right? Look at kubectl get svc -A | grep 10.42.0.200, that would give you a working example -- something with an externalIP/externalIPs set, or some status.loadbalancer.ingress array ... configuration may vary, depending on how external IPs were implemented and kube version, .. And by the way, creating such Services: are you pointing to your application directly, or is it sent to Traefik instead? Assuming the latter: are you sure Traefik actually listens on such port. Also, while Traefik should be able to process TCP or UDP trafic, unless you can easily have several Services & backends accessible through the same proto/port combination: involving your ingress controller here might not be necessary.

I would recommend running containers using docker-compose and use "environment" directive. https://docs.docker.com/compose/gettingstarted/ From this link above is a good example, see step 5. Also you can create .env file in the same directory as the the docker-compose.yml See examples in this link below. https://docs.docker.com/compose/environment-variables/ If you don't want use docker-compose, you can use --env flag: docker run --env VAR1=value1 --env VAR2=value2 ubuntu env

As far as I can see, you can only use Webhook on an actual repository that will call some service on your docker host. Docker host must be aware somehow. That is how to set up webhook. https://learn.microsoft.com/en-us/azure/devops/service-hooks/services/webhooks?view=azure-devops So flow is something like: create microservice on docker host create webhook on docker Azure repo 2 URL will be 1 endpoint 1 can be run as docker user, so you have permission to execute docker build and so on. I would do it this way.

You could try using the --profile option during the build. version: "3" services: strapi: profiles: ["strapi"] build: context: ./ dockerfile: strapi/Dockerfile container_name: "strapi" restart: always ports: - "3000:3000" nuxt: build: profiles: ["nuxt"] context: ./ dockerfile: nuxt/Dockerfile image: nuxt:latest container_name: "nuxt" restart: always ports: - "3000:3000" Then pass the profile switch during the build: docker compose --profile nuxt build Please refer to the official documentation for more information: https://docs.docker.com/compose/profiles/

To ensure a stack is in a consistent state after an upgrade, see the documentation on https://docs.docker.com/compose/compose-file/compose-file-v3/#update_config . failure_action defaults to pause so you need to set it to continue to ensure docker updates the services regardless. services: proxy: deploy: update_config: on_failure: continue backend: deploy: update_config: on_failure: continue That said - docker does not support green/blue deployments - but it is possible to use network aliases to ensure proxy:2 does not route to backend:1. Something like this for e.g.: services: proxy: image: proxy:${VER} environment: BACKEND_HOST: backend-${VER} backend: image: backend:${VER} networks: default: aliases: ["backend-${VER}"] To achieve your final requirement, you need to set the update_config parallelism to 1, and ensure that the order is set to start-first. A naive deployment would have a race condition if "proxy:2" is available before "backend:2" is available, but as long as there is a healthcheck, "proxy:2" can prevent itself receiving traffic until it has a successful connection test to "backend-2" services: proxy: image: proxy:${VER} environment: BACKEND_HOST: backend-${VER} healthcheck: ["CMD", "/bin/sh","-c","test_backend.sh"] Of course, you can run into problems if "proxy:2" finishes deploying, but "backend:2" errors out - you could eventually have a situation where you have no proxy:1 running, only proxy:2, but only backend:1 running and no backend:2. So you want to ensure the update_config delays updating the next task until the current one is health - or pause if that never happens. PS. It seems potentially much less hassle to just design and code around the principal that backwards compatibility of +-1 version is expected.

It'll probably really depend on your budget. 8GB RAM seems like very little, as bahrep suggested I would first try to see if your laptop can get a RAM upgrade. If you can afford it you could also do your experiments in the cloud. It depends on what you want to learn (DevOps is a large field) but chances are you'll have to get acquainted with the cloud. If your current hardware does not allow you to run multiple infrastructures at once I would look into VM/VPS purchasing: you'll get the resources you need and get to learn about major cloud providers in the meantime.

It is possible to run containers as a regular user using https://podman.io/ (buzzword: https://github.com/containers/podman#rootless ). Note that while podman is based on the same OCI standard as docker, there are some differences in the details. For example, healthchecks are specific to docker.

You're trying to copy just the /venv directory, but that's not going to work. Take a look at the contents of that directory, for example: root@52bdcc57abd8:/# python3 -m venv /venv root@52bdcc57abd8:/# ls -l /venv/bin/ total 48 -rw-r--r-- 1 root root 8834 Oct 22 03:52 Activate.ps1 -rw-r--r-- 1 root root 1880 Oct 22 03:52 activate -rw-r--r-- 1 root root 829 Oct 22 03:52 activate.csh -rw-r--r-- 1 root root 1969 Oct 22 03:52 activate.fish -rwxr-xr-x 1 root root 222 Oct 22 03:52 pip -rwxr-xr-x 1 root root 222 Oct 22 03:52 pip3 -rwxr-xr-x 1 root root 222 Oct 22 03:52 pip3.9 lrwxrwxrwx 1 root root 7 Oct 22 03:51 python -> python3 lrwxrwxrwx 1 root root 22 Oct 22 03:51 python3 -> /usr/local/bin/python3 lrwxrwxrwx 1 root root 7 Oct 22 03:51 python3.9 -> python3 As you can see /venv/bin/python3 isn't actually a file, it' just a symlink to whichever version of Python was used to create the virtual environment. You won't get away with just copying the binary, either, because you need the full set of runtime files from /usr/local/lib/python3.9, as well as any shared libraries that are by required by Python. But when replacing base image with debian:11-slim everything works as expected. In this case, you're installing a compatible version of Python...but if you're going to do that, you might as well just stick with the python:3.9-slim image.

https://learn.microsoft.com/en-us/archive/blogs/waws/things-you-should-know-web-apps-and-linux#you-can-only-expose-one-port-to-the-outside-worldapplies-to-web-app-for-containers . Azure Web App for Containers detect port 3000 first (3000 Revers proxy in container will resolve your problem. Test outside of container will not work. For test you may be change port 3000 to 8082. Backend /services/* will available, but frontend won't.

Your link directs to a public GitHub org. It would also appear that their repositories are licensed under Apache 2.0 so you should be able to use these more or less how you see fit (obviously within Apache 2.0, but that is quite permissible). This is further bolstered on their website by their statement here https://community.synopsys.com/s/document-item?bundleId=integrations-detect&topicId=introduction.html&_LANG=enus where they state: "...It is available through GitHub, under the permissive Apache License, Version 2.0 and does not require pre-installation or configuration." Looks like you should be able to just pull down the repo and get cracking.

At a minimum you need access to the shell. Without the shell, you will work as if you were 20 years ago or more. If you will host just one web application, at least you also need a public ip or domain preferable with https Also the usage of environment variables to avoid hardcoded values are required. The following strategies assume that you have shell access and a public ip or domain. let's not reinvent the wheel Dokku Dokku is an open-source platform-as-a-service (PaaS). If you're familiar with Heroku, you can consider Dokku a private Heroku that you manage. Basically, after the installation, you will have a private git url in which if you push some standard code, the app will be deployed. https://blog.back4app.com/what-is-dokku/ https://vimeo.com/68631325 https://www.freecodecamp.org/news/how-to-build-your-on-heroku-with-dokku/ I don't know any other similar open source platform. Buddy https://buddy.works/pricing In this platform you could automate some tasks. It is like a mini jenkins Minimal manual implementation Create a github repository Add a Dockerfile to your source code Use environment variables instead hardcoded values of database connection in the source code Install docker and git in the server Start a mongodb using docker and volumes After tests on your localhost, push to github Enter to the cloud and clone the git repository Execute the docker build to generate the image Execute docker run -p 80:xyz. xyz* is the port of your application

If you have a directory named te,"st, it's trivial to work with using -v: just quote it, keeping in mind that if you have a double quote inside a double quote you need to escape it. So this works: $ mkdir te,\"st $ touch te,\"st/file1 $ docker run --rm -v "$PWD/te,\"st:/data" alpine ls /data file1 For --mount it's a little trickier. From https://github.com/docker/cli/issues/1480 we know that the argument to --mount is parsed using CSV syntax, so we can use typical CSV escaping to take of things (quote fields that contain commas, and double-quote to escape quotes ("")): $ docker run --rm --mount "type=bind,\"src=$PWD/te,\"\"st\",target=/data" alpine ls /data file1

On inspection $ kubectl describe pod hello-minikube $ kubectl get nodes I found that I was running x86 container on ARM Macbook M1. Installed on x86 Linux and everything works as expected https://github.com/kubernetes/minikube/issues/13129

There are several ways to address this particular problem. Using a dynamic proxy Using a dynamic proxy is nice because you only need a single ip address and port. Incoming requests are directed to the appropriate container based on metadata about the request (such as the hostname, or particular headers, or the request path, etc). This is actually what I'm doing at home: I have a number of web services running on my local system and I want to access them by name. I'm handling this by using https://traefik.io/ , a dynamic proxy designed to work well with systems like Docker. Configuration is primarily via Docker labels. So for example, if I start the Traefik container like this: docker run -d --name traefik \ -v /var/run/docker.sock:/var/run/docker.sock \ -p 80:80 \ -p 127.0.0.1:8080:8080 \ docker.io/traefik:v2.8 \ --api.insecure=true \ --providers.docker (That -p 127.0.0.1:8080:8080 is exposing the Traefik dashboard on http://localhost:8080.) Then I can make a web service available at grafana.local by starting it like this: docker run -d --name grafana \ -l 'traefik.http.routers.grafana.rule=Host(`grafana.local`)' \ docker.io/nginx:mainline Now any host on my network can access that service at http://grafana.local (assuming I have arranged for the hostname "grafana.local" to map to the address of the host running the traefik proxy). I've used docker run commands here, but you can obviously set this all up using docker-compose instead. Using multiple ip addresses It sounds a bit like docker can not share the same port even when it belongs to several IPs on the host. That is in fact not true. Consider this; on my host I have the following addresses assigned on eth0: $ ip -4 addr show eth0 2: eth0: mtu 1500 qdisc fq_codel state UP group default qlen 1000 altname eno2 altname enp0s31f6 inet 192.168.1.175/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0 valid_lft 83583sec preferred_lft 83583sec inet 192.168.1.180/24 scope global secondary eth0 valid_lft forever preferred_lft forever inet 192.168.1.181/24 scope global secondary eth0 valid_lft forever preferred_lft forever inet 192.168.1.182/24 scope global secondary eth0 valid_lft forever preferred_lft forever Let's start up a few containers: docker run -d --name darkhttpd -p 192.168.1.180:80:8080 docker.io/alpinelinux/darkhttpd docker run -d --name nginx -p 192.168.1.181:80:80 docker.io/nginx:mainline docker run -d --name httpd -p 192.168.1.182:80:80 docker.io/httpd:2.4 We can see that the containers are all running successfully: $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 283c8e061ebc httpd:2.4 "httpd-foreground" 16 seconds ago Up 15 seconds 192.168.1.182:80->80/tcp httpd 0d2960c07212 nginx:mainline "/docker-entrypoint.…" 18 seconds ago Up 18 seconds 192.168.1.181:80->80/tcp nginx 68e56ed8c180 alpinelinux/darkhttpd "darkhttpd /var/www/…" 18 seconds ago Up 18 seconds 192.168.1.180:80->8080/tcp darkhttpd And I get different services depending on which IP address I use: $ curl 192.168.1.180 / ... $ curl 192.168.1.181 Welcome to nginx!

Yes your understanding is correct. The full documentation is here https://docs.github.com/en/actions/using-jobs/running-jobs-in-a-container

I'm struggling to understand the rationale of using Docker where the environments are essentially the same, and the applications are relatively simple. In reality, it is highly unlikely that any development environment on any project would ever be anywhere near the same as staging/production. Services running in staging/production will nearly always be physically hosted and managed somewhere which is not intended to be operated interactively by a human day-to-day, with an appropriate IT/security profile to match; The nature of development work, and even internal build/testing typically requires a different IT profile to that of a production server. Developers rarely have control over the underlying infrastructure or the organisation's IT/security policies. There are many ways in which the IT profile of developer environments, including build agents and even test machines, can deviate from production: Users/permissions or other security settings. Installed tools, SDKs, runtimes, debug/test tools, OS features/packages, and other dependencies operating with debug/test configurations enabled. Environment variables Filesystem structure and the content of files in globally shared directories Configurations of globally-installed dependencies such as web servers. Furthermore, consider the nature of physical devices and VMs They are stateful and mutable Every change to any aspect of a device or VM, including installed software and configuration changes potentially affects its entire state for all processes running on it. Physical devices and VMs typically run many processes/services concurrently, it would usually not be considered economical to have a whole server or VM just for a single running process. What containers provide: Isolation from the host device/VM and from an organisation's IT, Network and Infrastructure policies. Isolation from each other - for example, consider the issue of requiring multiple versions of globally-installed runtime dependencies or modifications to shared host resources such as environment variables or local files. Developers typically have full control over their choices of container images and the networking/orchestration inside the container runtime. Images are based on immutable layers, meaning it is not possible for the state of any layer in an image to change, so a published image should always be a good, known, valid starting point. The size of a parent image tends to be inconsequential because there's typically no reason to duplicate nor to re-download it unless a new version of that parent image is published. A container is its own thin, mutable layer on top of an image, usually negligible in size, and uses the parent image for all dependencies. if a container ends up in an invalid state, it may be quickly and cheaply disposed and replaced with a fresh, clean new container almost instantly by recreating another fresh new container layer. The cheap, light-weight nature of containers makes it very efficient to run a single process per-container.

I think I fixed the issue. It seems it comes up, when the kubelet service starts before the docker service is up and running. So I added the directive After=docker.service to the [Unit] block of the kubelet service and restarted it. The issue seems to be gone now.