2
First a couple key points:
Tags are mutable in most registries, so v1 today may be different from v1 a month ago. However clients do need to pull this tag again to see the updates.
Multiple tags may point to the same image. So stable and v1 could point to the same image.
Pointing to a digest ensures the image is immutable, however you will not receive ...
1
I don't know if this is a good practice or not, but I usually create 2 docker files.
One just runs the application and the other runs a multi-stage build (including test), the latter is only used by the developer, the former is the one used on CI.
1
For now I gave up on this approach after stumbling over this paragraphs in the Redis cluster documentation:
Currently Redis Cluster does not support NATted environments and in general environments where IP addresses or TCP ports are remapped.
Docker uses a technique called port mapping: programs running inside Docker containers may be exposed with a ...
1
To increase the start up time, you need to "bake" (install) more of what is in your start up script into the image.
Snapshotting is one method, but I would avoid manually creating instances and then taking snapshots.
A better approach is to automate the creation of these images. Hashicorp Packer is the most common tool used for doing this. You can ...
1
The only issue you might have running the same services in containers as locally on your machine is a port conflict. Let's take httpd as an example:
You try and start the container and you get listen tcp 0.0.0.0:80: bind: address already in use. This is because a HTTP server is already running on your machine.
Tell docker to bring the container up using a ...
1
The problem was that I was declaring:
ARG GITLAB_ACCESS_TOKEN
BEFORE the FROM statement and it has to be done AFTER it.
1
It's really up to your personal preference, but for minikube you can certainly follow the same standards that you would for production.
If your production environment will use some sort of volume mount for your application code, then follow that same workflow for local dev and just have a pod running that mounts to your local code.
If your production ...
1
It seems that this is still an ongoing issue. No metadata is available (contained in the image itself) that provides information about last usage.
You can try to implement your own script/tool that monitors docker events and keeps track of image usage and prunes older ones. For example, docker events --since 24h --filter event=start --format '{{ .Time }} {{ ....
1
Solved it:
docker network ls
47ebbf46f26d bridge bridge local
docker network inspect bridge
the bridge ip was still 172.17.0.0/16
So alter the bridge ip in daemon.json
cat /etc/docker/daemon.json
{
"bip": "10.200.200.90/24",
}
restart docker daemon and bridge is working and we can push to the registry
1
The error you are getting is from your Kubernetes cluster being unable to pull container image from GitLab.
Providing a temporary credential to pull the containers as deploy time is not a great solution. For example, say your Kubernetes cluster needs to scale up by adding another node, the node will come up and try and pull the container, but the secret will ...
Only top voted, non community-wiki answers of a minimum length are eligible
