i am a Novice in Docker and wanted to use Sensu for monitoring containers. I have set up a Sensu server and Sensu client ( where my Docker containers are running ) using the below material:
Click [here] (http://devopscube.com/monitor-docker-containers-guide/)
I get the Sensu client information in Uchiwa Dashboard while running the below command:
docker run -d --name sensu-client --privileged \
-v $PWD/load-docker-metrics.sh:/etc/sensu/plugins/load-docker-metrics.sh \
-v /var/run/docker.sock:/var/run/docker.sock \
usman/sensu-client SENSU_SERVER_IP RABIT_MQ_USER RABIT_MQ_PASSWORD CLIENT_NAME CLIENT_IP
However, when i try to fire a new container from the same host machine , i do not get the information of the client in Uchiwa Dashboard.
It would be great if anyone have used Sensu with Docker to monitor Docker containers can guide on the same.
Thanks for the time.
Please logs of the sensu-client
'Supervisord is running as root and it is searching '
2017-01-09 04:11:47,210 CRIT Supervisor running as root (no user in config file)
2017-01-09 04:11:47,212 INFO supervisord started with pid 12
2017-01-09 04:11:48,214 INFO spawned: 'sensu-client' with pid 15
2017-01-09 04:11:49,524 INFO success: sensu-client entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2017-01-09 04:11:49,530 INFO exited: sensu-client (exit status 0; expected)
[ec2-user#ip-172-31-0-89 sensu-client]$ sudo su
[root#ip-172-31-0-89 sensu-client]# docker logs sensu-client
/usr/lib/python2.6/site-packages/supervisor-3.1.3-py2.6.egg/supervisor/options.py:296: UserWarning: Supervisord is running as root and it is searching for its configuration file in default locations (
including its current working directory); you probably want to specify a "-c" argument specifying an absolute path to a configuration file for improved security.
'Supervisord is running as root and it is searching '
2017-01-09 04:11:47,210 CRIT Supervisor running as root (no user in config file)
2017-01-09 04:11:47,212 INFO supervisord started with pid 12
2017-01-09 04:11:48,214 INFO spawned: 'sensu-client' with pid 15
2017-01-09 04:11:49,524 INFO success: sensu-client entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2017-01-09 04:11:49,530 INFO exited: sensu-client (exit status 0; expected)
Related
I have downloaded Karate Chrome docker image from Docker Hub. When I am starting karate chrome docker with below command, I am seeing chrome is not starting when I spin up the container.
docker run --name karate --rm -p 9222:9222 -p 5900:5900 -e KARATE_SOCAT_START=true --cap-add=SYS_ADMIN ptrthomas/karate-chrome
I am able to spin up a container on my local Macbook but when I am trying to spin up the same image on my organization Macbook, it is throwing me an error. Do you know what it could be? Is it because of VPN? I disconnected VPN and tried but same response
Expected Result: Able to spin up a container with Chrome.
Actual Result: Not able to open Chrome.
Below are some logs.
INFO reaped unknown pid 2764(exit status 0)
INFO reaped unknown pid 2783(terminated by SIGTRAP)
INFO reaped success: chrome entered RUNNING state,process has stayed up for > than 1 seconds
INFO reaped unknown pid 2824(exit status 0)
INFO exited: chrome (terminate by SIGTRAP; not expected)
INFO reaped unknown pid 2810(exit status 0)
INFO reaped unknown pid 2815(exit status 0)
INFO reaped spawned: 'chrome' with pid 2828
INFO reaped unknown pid 2801(terminated by SIGPIE)
INFO reaped unknown pid 2802(terminated by SIGTRAP)
These logs keeps flowing up and everytime it is changing the port number.
Most likely because the Docker container is not yet ready for Apple silicon / ARM / M1 / M2.
You should be able to build your own Docker image looking at the source. We welcome contributions to make this work across all kinds of hardware.
I am testing out SonarQube locally on my machine using docker, however the docker container keeps stopping, not sure why this is the case. Am using Mac and am not sure if the Java version affects SonarQube but am running Java version 11 on my machine.
These are the logs I am getting
2021.07.22 16:49:46 INFO app[][o.s.a.AppFileSystem] Cleaning or creating temp directory /opt/sonarqube/temp
2021.07.22 16:49:46 INFO app[][o.s.a.es.EsSettings] Elasticsearch listening on [HTTP: 127.0.0.1:9001, TCP: 127.0.0.1:39173]
2021.07.22 16:49:46 INFO app[][o.s.a.ProcessLauncherImpl] Launch process[[key='es', ipcIndex=1, logFilenamePrefix=es]] from [/opt/sonarqube/elasticsearch]: /opt/sonarqube/elasticsearch/bin/elasticsearch
2021.07.22 16:49:47 INFO app[][o.s.a.SchedulerImpl] Waiting for Elasticsearch to be up and running
2021.07.22 16:49:47 WARN app[][o.s.a.p.AbstractManagedProcess] Process exited with exit value [es]: 1
2021.07.22 16:49:47 INFO app[][o.s.a.SchedulerImpl] Process[es] is stopped
2021.07.22 16:49:47 INFO app[][o.s.a.SchedulerImpl] SonarQube is stopped
This is the command I used to run the docker container
docker run --name sonarqube --restart always -p 9000:9000 -d sonarqube
What am I missing?
I updated the version of docker on my machine to the latest(Been skipping for almost a year) and it worked
Does anyone know how to pass custom Kafka configuration options to the landoop/fast-data-dev docker image?
Since there is no way to puss a custom config file and/or config params, what I've tried so far was to mount my own server.properties config file into /opt/confluent/etc/kafka by adding the following into my docker compose file
landoop:
hostname: 'landoop'
image: 'landoop/fast-data-dev:latest'
expose:
- '3030'
ports:
- '3030:3030'
environment:
- RUNTESTS=0
- RUN_AS_ROOT=1
volumes:
- ./docker/landoop/tmp:/tmp
- ./docker/landoop/opt/confluent/etc/kafka:/opt/confluent/etc/kafka
however, this causes Kafka to throw the following logs:
landoop_1 | 2017-09-28 11:53:03,886 INFO exited: broker (exit status 1; not expected)
landoop_1 | 2017-09-28 11:53:04,749 INFO spawned: 'broker' with pid 281
landoop_1 | 2017-09-28 11:53:05,851 INFO success: broker entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
landoop_1 | 2017-09-28 11:53:11,867 INFO exited: rest-proxy (exit status 1; not expected)
landoop_1 | 2017-09-28 11:53:12,604 INFO spawned: 'rest-proxy' with pid 314
landoop_1 | 2017-09-28 11:53:13,024 INFO exited: schema-registry (exit status 1; not expected)
landoop_1 | 2017-09-28 11:53:13,735 INFO spawned: 'schema-registry' with pid 341
landoop_1 | 2017-09-28 11:53:13,739 INFO success: rest-proxy entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
in addition, when I go to http://localhost:3030/kafka-topics-ui/, I see the following:
KAFKA REST
/api/kafka-rest-proxy
CONNECTIVITY ERROR
Any suggestions? Thank you.
There are couple of things that i did which simplified the whole process. This is valid only for dev environment
Start the docker with a interactive shell as the entry point
Start the docker on the host network
Make necessary changes to the server.properties file include the host IP where the docker was running (as mentioned in (2) docker is running on host network)
** 4. If you want to make any advanced configuration, you may do now**
Run the actual entry point "/usr/local/bin/setup-and-run.sh"
Actual commands used:
Start the container
sudo docker run -it --entrypoint /bin/bash --net=host --rm -e ADV_HOST=HOSTIP landoop/fast-data-dev:latest
Add following to /run/broker/server.properties
advertised.host.name = HOST-IP
advertised.port = 9092
Run /usr/local/bin/setup-and-run.sh
At today, with latest version of landoop/fast-data-dev is possible to specify custom Kafka configuration options by converting the configuration option to uppercase, replacing dots with underscores and prepending with KAFKA_.
For example if you want to set specific values for "log.retention.bytes" and "log.retention.hours" you should add the following to your docker compose environment section:
environment:
KAFKA_LOG_RETENTION_BYTES: 1073741824
KAFKA_LOG_RETENTION_HOURS: 48
ADV_HOST: 127.0.0.1
RUNTESTS: 0
BROWSECONFIGS: 1
You can specify this way also configuration options for other services ( schema registry, connect, rest proxy ). Check doc for details https://hub.docker.com/r/landoop/fast-data-dev/.
Once the container is up you can confirm this by looking at configuration file at the following path inside the container:
/run/broker/server.properties
or also through the Landoop UI at the following URL if you've set "BROWSECONFIGS" to 1 on the environments parameters:
http://127.0.0.1:3030/config/broker/server.properties
I have 3 CentOS VMs and I have installed Zookeeper, Marathon, and Mesos on the master node, while only putting Mesos on the other 2 VMs. The master node has no mesos-slave running on it. I am trying to run Docker containers so i specified "docker,mesos" in the containerizes file. One of the mesos-agents starts fine with this configuration and I have been able to deploy a container to that slave. However, the second mesos-agent simply fails when I have this configuration (it works if i take out that containerizes file but then it doesn't run containers). Here are some of the logs and information that has come up:
Here are some "messages" in the log directory:
Apr 26 16:09:12 centos-minion-3 systemd: Started Mesos Slave.
Apr 26 16:09:12 centos-minion-3 systemd: Starting Mesos Slave...
WARNING: Logging before InitGoogleLogging() is written to STDERR
[main.cpp:243] Build: 2017-04-12 16:39:09 by centos
[main.cpp:244] Version: 1.2.0
[main.cpp:247] Git tag: 1.2.0
[main.cpp:251] Git SHA: de306b5786de3c221bae1457c6f2ccaeb38eef9f
[logging.cpp:194] INFO level logging started!
[systemd.cpp:238] systemd version `219` detected
[main.cpp:342] Inializing systemd state
[systemd.cpp:326] Started systemd slice `mesos_executors.slice`
[containerizer.cpp:220] Using isolation: posix/cpu,posix/mem,filesystem/posix,network/cni
[linux_launcher.cpp:150] Using /sys/fs/cgroup/freezer as the freezer hierarchy for the Linux launcher
[provisioner.cpp:249] Using default backend 'copy'
[slave.cpp:211] Mesos agent started on (1)#172.22.150.87:5051
[slave.cpp:212] Flags at startup: --appc_simple_discovery_uri_prefix="http://" --appc_store_dir="/tmp/mesos/store/appc" --authenticate_http_readonly="false" --authenticate_http_readwrite="false" --authenticatee="crammd5" --authentication_backoff_factor="1secs" --authorizer="local" --cgroups_cpu_enable_pids_and_tids_count="false" --cgroups_enable_cfs="false" --cgroups_hierarchy="/sys/fs/cgroup" --cgroups_limit_swap="false" --cgroups_root="mesos" --container_disk_watch_interval="15secs" --containerizers="docker,mesos" --default_role="*" --disk_watch_interval="1mins" --docker="docker" --docker_kill_orphans="true" --docker_registry="https://registry-1.docker.io" --docker_remove_delay="6hrs" --docker_socket="/var/run/docker.sock" --docker_stop_timeout="0ns" --docker_store_dir="/tmp/mesos/store/docker" --docker_volume_checkpoint_dir="/var/run/mesos/isolators/docker/volume" --enforce_container_disk_quota="false" --executor_registration_timeout="1mins" --executor_shutdown_grace_period="5secs" --fetcher_cache_dir="/tmp/mesos/fetch" --fetcher_cache_size="2GB" --frameworks_home="" --gc_delay="1weeks" --gc_disk_headroom="0.1" --hadoop_home="" --help="false" --hostname_lookup="true" --http_authenticators="basic" --http_command_executor="false" --http_heartbeat_interval="30secs" --initialize_driver_logging="true" --isolation="posix/cpu,posix/mem" --launcher="linux" --launcher_dir="/usr/libexec/mesos" --log_dir="/var/log/mesos" --logbufsecs="0" --logging_level="INFO" --max_completed_executors_per_framework="150" --oversubscribed_resources_interval="15secs" --perf_duration="10secs" --perf_interval="1mins" --qos_correction_interval_min="0ns" --quiet="false" --recover="reconnect" --recovery_timeout="15mins" --registration_backoff_factor="1secs" --revocable_cpu_low_priority="true" --runtime_dir="/var/run/mesos" --sandbox_directory="/mnt/mesos/sandbox" --strict="true" --switch_user="true" --systemd_enable_support="true" --systemd_runtime_directory="/run/systemd/system" --version="false" --work_dir="/var/lib/mesos"
[slave.cpp:541] Agent resources: cpus(*):1; mem(*):919; disk(*):2043; ports(*):[31000-32000]
[slave.cpp:549] Agent attributes: [ ]
[slave.cpp:554] Agent hostname: node3
[status_update_manager.cpp:177] Pausing sending status updates
[state.cpp:62] Recovering state from '/var/lib/mesos/meta'
[state.cpp:706] No committed checkpointed resources found at '/var/lib/mesos/meta/resources/resources.info'
[status_update_manager.cpp:203] Recovering status update manager
[docker.cpp:868] Recovering Docker containers
[containerizer.cpp:599] Recovering containerizer
[provisioner.cpp:410] Provisioner recovery complete
[group.cpp:340] Group process (zookeeper-group(1)#172.22.150.87:5051) connected to ZooKeeper
[group.cpp:830] Syncing group operations: queue size (joins, cancels, datas) = (0, 0, 0)
[group.cpp:418] Trying to create path '/mesos' in ZooKeeper
[detector.cpp:152] Detected a new leader: (id='15')
[group.cpp:699] Trying to get '/mesos/json.info_0000000015' in ZooKeeper
[zookeeper.cpp:259] A new leading master (UPID=master#172.22.150.88:5050) is detected
Failed to perform recovery: Collect failed: Failed to run 'docker -H unix:///var/run/docker.sock ps -a': exited with status 1; stderr='Cannot connect to the Docker daemon. Is the docker daemon running on this host?'
To remedy this do as follows:
Step 1: rm -f /var/lib/mesos/meta/slaves/latest
This ensures agent doesn't recover old live executors.
Step 2: Restart the agent.
Apr 26 16:09:13 centos-minion-3 systemd: mesos-slave.service: main process exited, code=exited, status=1/FAILURE
Apr 26 16:09:13 centos-minion-3 systemd: Unit mesos-slave.service entered failed state.
Apr 26 16:09:13 centos-minion-3 systemd: mesos-slave.service failed.
Logs from docker:
$ sudo systemctl status docker
● docker.service - Docker Application Container Engine Loaded:
loaded (/usr/lib/systemd/system/docker.service; disabled; vendor preset: disabled)
Drop-In: /usr/lib/systemd/system/docker.service.d
└─flannel.conf Active: inactive (dead) since Tue 2017-04-25 18:00:03 CDT;
24h ago Docs: docs.docker.com Main PID: 872 (code=exited, status=0/SUCCESS)
Apr 26 18:25:25 centos-minion-3 systemd[1]: Dependency failed for Docker Application Container Engine.
Apr 26 18:25:25 centos-minion-3 systemd[1]: Job docker.service/start failed with result 'dependency'
Logs from flannel:
[flanneld-start: network.go:102] failed to retrieve network config: client: etcd cluster is unavailable or misconfigured
You have answer in your logs
Failed to perform recovery: Collect failed:
Failed to run 'docker -H unix:///var/run/docker.sock ps -a': exited with status 1;
stderr='Cannot connect to the Docker daemon. Is the docker daemon running on this host?'
To remedy this do as follows:
Step 1: rm -f /var/lib/mesos/meta/slaves/latest
This ensures agent doesn't recover old live executors.
Step 2: Restart the agent.
Mesos keeps it state/metadata on local disk. When it's restarted it try to load this state. If configuration changed and is not compatible with previous state it won't start.
Just bring docker to live by fixing problems with flannel and etcd and everything will be fine.
add the following flag while starting agent,
--reconfiguration_policy=additive
more details here: http://mesos.apache.org/documentation/latest/agent-recovery/
I have simple Docker image built over ubuntu with dummy laravel php application.
I use supervisord to start nginx and php-fpm.
So far so good, everything works fine in my local machine or in any place where docker executable exists.
I'm trying to run same image in the Jelastic environment but I'm getting supervisord errors:
2017-01-21 14:34:30,283 INFO exited: cron (exit status 1; not expected)
2017-01-21 14:34:30,333 INFO exited: fpm (exit status 78; not expected)
2017-01-21 14:34:32,336 INFO spawned: 'cron' with pid 1216
2017-01-21 14:34:32,338 INFO spawned: 'fpm' with pid 1217
2017-01-21 14:34:32,341 INFO exited: cron (exit status 1; not expected)
2017-01-21 14:34:32,386 INFO exited: fpm (exit status 78; not expected)
I've contacted support and they told me that cron and php-fpm are already running because of systemd, so they logged in to my node, fixed something and now everything is running.
I'm wondering how this aligns with "Native Docker™© support"™ tagline everywhere in the documentation.
Anyways, I've setup new sample app for support investigation (image – https://hub.docker.com/r/rozhok/jelastic-laravel-docker/ sources – https://github.com/rozhok/jelastic-laravel-docker), tried to deploy it and everything worked fine all of sudden.
So my questions is:
How to avoid supervisord and systemd clashes when deploying to Jelastic. Remember, I want to have same image for all my environments, and I don't want to prepare "special" images for Jelastic.
Is there any other caveats we should know about? Maybe Docker support should be described a bit more.
It seems that you need to add only one extra line to your Dockerfile:
RUN systemctl disable php-fpm
that will disable php-fpm from being spawned from your systemd process, your process will be definitely started by supervisor and that will make the image to be compatible for both Jelastic and your docker host running on your local machine.