I've been experimenting and searching for a long time without finding an answer that works.
I have a Windows Container and I need to embed a startup script for each time a new container is created.
All the answers I found suggest one of the following:
Add the command to the dockerfile - this is not good because it will only run when the image is built. I need it to run every single time a new container is created from the image,
use docker exec after starting a container - this is also not what I need. These images are intended to be "shippable". I need the script to run without any special action apart from creating a new container.
Using ENTRYPOINT - I had 2 cases here. It either fails and immediately exits. Or it succeeds but the container stops. I need it to keep running.
Basically, the goal of this is to do some initial configuration on the container when it starts and keep it running.
The actions are around generating a GUID and registering the hostname. These have to be unique which is why I need to run them immediately when the container starts.
Looks like CMD in the dockerfile is all I needed. I used:
CMD powershell -file
I simply checked in the script if it's the first time it is running
Related
I have a pod named 'sample_pod' and a container named 'sample_container' running inside the pod. sample_container's entry point is a python bin file (sample.py). Inside this container, I have CRL certificates which gets refreshed every one hour and sample.py does not know about the refreshed certificates without reloading it.
I need to reload that container every one hour without killing/restarting that container. This is exactly similar to systemd reload option. Is there any specific command to reload that I can run/schedule for every one hour inside sample_container?
If so, how can I schedule to run that command inside container every one hour? Or is there a kubernetes native approach to achieve this?
For your use case, just do not use containers but use instead classical server with a cron task. (cf. my comment under your question)
Let's say I want to execute a cleanup script whenever container termination is triggered. How do I go about this using docker-compose?
This could be handy to automatically back up the files, databases, etc for the dev container.
docker containers are meant to be ephemeral:
By "ephemeral", we mean that the container can be stopped and destroyed, then rebuilt and replaced with an absolute minimum set up and configuration.
Building upon this concept docker itself does not offer anything to hook into the shutdown process. docker-compose is built on top of docker and also does not add such functionality.
Maybe you can rethink your problem the docker way to better fit the intended use of docker. Without further context it is hard to say what could be a good solution but maybe one of the following approaches helps you out:
docker stop sends a SIGTERM signal to the main process in the container. You could use a custom entrypoint or supervisor process that would trigger the appropriate actions on a SIGTERM. This approach requires custom containers. With the stop_signal attribute you can also configure a custom signa to be sent in your docker-compose.yml
if you just want to persist data files from the containers just configuring the right volumes might be enough
you could use docker events to listen and act upon any types of events emitted by the docker daemon
I have a problem with docker compose and build order. Below is my dockerfile for starting my .net application
As you can see as part of my build process I run some tests using "RUN dotnet test backend_test/backend_test.csproj"
These tests require a mongodb database to be present.
I try to solve this dependency with docker-compose and its "depends_on" feature, see below.
However this doesn't seem to work as when I run "docker-compose up" I get the following:
The tests eventually timeout since there is no mongodb present.
Does depends_on actually affect build order at all or does it only affect start-order (i.e builds everything the proceeds to start in correct order) ?
Is there another way of doing this ? (I want tests to run as part of building my final app)
Ty in advance, let me know If you need extra information
As you guessed, depends_on is for runtime order only, not build time - it just affects docker-compose up and docker-compose stop.
I highly recommend you make all the builds independent of each other. Perhaps you need to consider separate builder and runtime images here, and / or use a Docker-based CI (Gitlab, Travis, Circle etc) to have these dependencies available for testing.
Note also, depends_on often disappoints people - as it just waits for Docker's startup to finish, not the application startup. So your DB / service / whatever may still be starting up when the container that depends on it start will start using it, causing timeouts etc. This is why HEALTH_CHECK now exists (with a similar healthcheck feature in Docker Compose)
I found that startup scripts can be added to Google compute instances using either the console or cli(gcloud). I want to add the startup scripts to google container engine.
The goal is to notify me when the google container engine has changed its state to Running. I though one efficient way is to use startup scripts in container engine, as these scripts will only be executed when the container's status is changed to running.
Any idea how to add startup scripts to container engine or any other way of notifying when the container's status changes to running.
First of all your question is fairly complicated. The concept of startup scripts do not belong to the containers world. As far as I know you can't add startup scripts in Google Container Engine. This is because Container Engine instances are immutable (e.g. you can't or you are not supposed to modify the operating system, you should just run containers).
If you're trying to run scripts when a container starts/stops you need to forget about startup scripts concept in the Compute Engine world. You can use container lifecycle hooks in Kubernetes (the orchestrator running in Container Engine).
Here's documentation and tutorial about it:
https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/
https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/
You can approximate the behavior of startup scripts using a DaemonSet with a simple pod that runs in privileged mode. For example code, see https://github.com/kubernetes/contrib/tree/master/startup-script.
Project metadata works for this, here's a terraform example:
resource "google_compute_project_metadata_item" "main" {
project = abcdefg # this is optional
key = "startup-script"
value = "#! /bin/sh\necho hello > /tmp/world"
}
Say I have a container image that contains a large command-line program that is executed from the shell. I have another container that contains a scheduler whose job it is to invoke the first container when it receives a certain signal. For various reasons I don't want to put them in the same container (mainly because the scheduler can invoke many different tools, and different versions of those tools, and I don't want to have to put all the tools and their versions in the same container image.)
I know how to put two containers in the same pod. However, the default behavior is to run both containers at startup. What I want to be able to do is to have the scheduler be able to decide when to invoke the other container, and to be able to specify the command-line arguments (and ideally, environment variables) for it. Also, I need to know the exit status. Extra credit for getting stdout/stderr, but I can hack around with volumes if I need to.
I also know how to do this if the second container was a server, but in this case it's a shell program.
A quick way to do this is:
Add a kubectl proxy in your container startup
Then call a kubernetes job from the first pod.
This would create a lightweight solution in which the desired job can be queried for success state, seemingly fulfilling your requirements