I have been using docker to run images along with some options like:
docker run --net host --oom-kill-disable -d -p <port>:<port> image
How do I set values like --oom-kill-disable on marathon?
It is required for docker containers in their marathon spec to specify a boolean value for oom-kill-disable flag for executor to run properly.
So the spec would include:
"parameters": [
{ "key": "oom-kill-disable", "value": "true" }
]
I'm not quite sure if you can pass an empty value in this case, but you could go with something like this:
"container": {
"type": "DOCKER",
"docker": {
"network": "HOST",
"image": "your/image",
"parameters": [
{ "key": "oom-kill-disable", "value": "" }
]
}
}
You may read a little bit more here in "Privileged Mode and Arbitrary Docker Options" section.
Related
In an existing swarm, I created a service via a docker-compose yaml file using the 'docker stack' command.
When I check the service via 'docker service ls' command, the new service shows up on the list. it shows "0/1" in the REPLICAS column
When I check the service using the command below, it shows 'Running' as the Desired State
docker service ps --no-trunc (service id)
When I check if there is already a corresponding container for the service, I can see none
When I try to access the service via the browser, it seems to be not started.
What is difficult is I cannot see any logs to find the cause of why this is happening
docker service logs (service id)
I figured it may just be slow to start but I waited for about half an hour and it was still in that state. Not sure how can I find out the cause of this without any logs. Can anyone help me on this?
EDIT: Below is the result when I did a docker inspect of the service task
[
{
"ID": "wt2tdoz64j5wmci4gr3q3io2e",
"Version": {
"Index": 3407514
},
"CreatedAt": "2020-08-25T00:58:13.012900717Z",
"UpdatedAt": "2020-08-25T00:58:13.012900717Z",
"Labels": {},
"Spec": {
"ContainerSpec": {
"Image": "my-ui-image:1.8.006",
"Labels": {
"com.docker.stack.namespace": "myservice-stack"
},
"Env": [
"BACKEND_HOSTNAME=somewebsite.com",
"BACKEND_PORT=3421"
],
"Privileges": {
"CredentialSpec": null,
"SELinuxContext": null
},
"Hosts": [
"10.152.30.18 somewebsite.com"
],
"Isolation": "default"
},
"Resources": {},
"Placement": {},
"Networks": [
{
"Target": "lt87emwtgbeztof5k2r1z2v27",
"Aliases": [
"myui_poc2"
]
}
],
"ForceUpdate": 0
},
"ServiceID": "nbskoeofakkgxlgj3utgn45c5",
"Slot": 1,
"Status": {
"Timestamp": "2020-08-25T00:58:13.012883476Z",
"State": "new",
"Message": "created",
"PortStatus": {}
},
"DesiredState": "running"
}
]
If you store your images in private registry then you must be logged in by command docker login and deploy your services by docker stack deploy -c docker-compose.yml your_service --with-registry-auth.
From the docker service ps ... output, you will see a column with the task id. You can get further details of the state of that task by inspecting the task id:
docker inspect $taskid
My guess is that your app is not redirecting it's output to stdout and that's why you don't get any output when doing "docker service logs...".
I would start by looking at this: https://docs.docker.com/config/containers/logging/
How you redirect the apps output to stdout will depend on what language your app is developed in.
There's two distinct parameters in the /services/create endpoint, called Command and Args. The description says:
Command (array of string) – the command to be run in the image
Args (array of string) – arguments to the command
I was puzzled by the fact that Command is an array: if the command arguments can be passed to it (which seems to be the case as docker-py splits it as a shell command) what's the purpose of Args then?
My current guess: the purpose of Command and Args is the same as in Entrypoint and Cmd in regular Docker containers. Args are just appended to the Command:
POST /services/create
{
"Name": "test",
"TaskTemplate": {
"ContainerSpec": {
"Image": "ubuntu",
"Command": ["echo", "foo"],
"Args": ["bar"]
}
}
}
$ docker service logs test
test.1.npltmr9c69fz#hostname | foo bar
And if you omit the Command, it is taken from the image's entrypoint:
POST /services/create
{
"Name": "test2",
"TaskTemplate": {
"ContainerSpec": {
"Image": "ubuntu",
"Args": ["echo", "baz!"]
}
}
}
$ docker service logs test2
test2.1.c16waqqxtdgd#hostname | baz!
This is only a result of my empirical testing, so any solid documentation / source code proofs are appreciated!
I am trying to run my containers in mesos and outputting all logs to Cloudwatch. According to Docker documentation, I should pass the following to 'docker run':
--log-driver=awslogs --log-opt awslogs-region=us-east-1 --log-opt awslogs-group=myLogGroup
(from https://docs.docker.com/engine/admin/logging/awslogs/#awslogs-region)
to docker run. In order to achieve this using Marathon (or Chronos, I assume?) , I should add the following block to my configuration json file for my task
"parameters": [
{ "key": "hostname", "value": "a.corp.org" },
{ "key": "volumes-from", "value": "another-container" },
{ "key": "lxc-conf", "value": "..." }
]
https://mesosphere.github.io/marathon/docs/native-docker.html
It appears that this config appends the following to your docker run
--{key}={value}
Since I need to do something of the form "--log-opt awslogs-region=us-east-1", I am putting "key": "log-opt awslogs-region", "value": "us-east-1", which generates the docker run command correctly, as I can see from stderr in mesos. However, I then get an error saying
unknown flag: --log-opt awslogs-region
See 'docker run --help'.
Running the generated docker run command from stderr directly on the mesos slave works fine.
You can make use of the args parameter to pass custom docker run options,
"args": [
"--log-driver",
"awslogs"
]
Made computation docker which runs fine locally. Uploaded it to Gcloud and could run it. But what I really need is to run hundreds of instances with different argument each.
docker run -t dxyz arg0
docker run -t dxyz arg1
docker run -t dxyz arg2
...
What is the best way to do it? I tried Kubctl pods but looks like they supposed to be identical
This is pretty clunky due to the nesting and because it requires you to specify the replication controller's name and image twice, but you can technically use
kubectl run dxyz0 --image=dxyz --overrides='{"apiVersion": "v1", "spec": {"template": {"spec": {"containers": [ {"name:" "dxyz0", "image": "dxyz", "args": [ "arg0" ] } ] } } } }'
kubectl run dxyz1 --image=dxyz --overrides='{"apiVersion": "v1", "spec": {"template": {"spec": {"containers": [ {"name:" "dxyz1", "image": "dxyz", "args": [ "arg1" ] } ] } } } }'
...
I have a private Docker registry that is accessible at https://docker.somedomain.com (over standard port 443 not 5000). My infrastructure includes a set up of Mesosphere, which have docker containerizer enabled. I'm am trying to deploy a specific container to a Mesos slave via Marathon; however, this always fails with Mesos failing the task almost immediately with no data in stderr and stdout of that sandbox.
I tried deploying from an image from the standard Docker Registry and it appears to work fine. I'm having trouble figuring out what is wrong. My private Docker registry does not require password authentication (turned off for debugging this), AND if I shell into the Meso's slave instance, and sudo su as root, I can run a 'docker pull docker.somedomain.com/services/myapp' successfully every time.
Here is my Marathon post data for starting the task:
{
"id": "myapp",
"cpus": 0.5,
"mem": 64.0,
"instances": 1,
"container": {
"type": "DOCKER",
"docker": {
"image": "docker.somedomain.com/services/myapp:2",
"network": "BRIDGE",
"portMappings": [
{ "containerPort": 7000, "hostPort": 0, "servicePort": 0, "protocol": "tcp" }
]
},
"volumes": [
{
"containerPath": "application.yml",
"hostPath": "/var/myapp/application.yml",
"mode": "RO"
}
]
},
"healthChecks": [
{
"protocol": "HTTP",
"portIndex": 0,
"path": "/",
"gracePeriodSeconds": 5,
"intervalSeconds": 20,
"maxConsecutiveFailures": 3
}
]
}
I've been stuck on this for almost a day now, everything I've tried seems to be yielding the same result. Any insights on this would be much appreciated.
My versions:
Mesos: 0.22.1
Marathon: 0.8.2
Docker: 1.6.2
So this turns out to be an issue with volumes
"volumes": [
{
"containerPath": "/application.yml",
"hostPath": "/var/myapp/application.yml",
"mode": "RO"
}
]
Using the root path of the container of the root path may be legal in docker, but Mesos appears not to handle this behavior. Modifying the containerPath to a non-root path resolves this, i.e
"volumes": [
{
"containerPath": "/var",
"hostPath": "/var/myapp",
"mode": "RW"
}
]
If it is a problem between Marathon and the registry, the answer should be in the http logs of your registry. If Marathon connects, there will be an entry. And the Mesos master log should contain a clue as well.
It doesn't really sound like a problem between Marathon and Registry though. Are you sure you have 'docker,mesos' in /etc/mesos-slave/containerizers?
Did you --despite having no authentification-- try to follow Using a Private Docker Repository?
To supply credentials to pull from a private repository, add a .dockercfg to the uris field of your app. The $HOME environment variable will then be set to the same value as $MESOS_SANDBOX so Docker can automatically pick up the config file.