Redis GUI Redis-commander working on Docker - ERROR: Status: reconnecting - redis

I have installed Redis GUI redis-commander by using https://github.com/joeferner/redis-commander
Redis running on localhost:6379 as a container at docker.
This says if I run redis on localhost:6379, all I need to get started is;
docker run --rm --name redis-commander -d -p 8081:8081 ghcr.io/joeferner/redis-commander:latest
But I encountered with this problem... Is there anyone who got this error and found a solution for this ??

There are some things you have to take into account.
Redis commander is running inside a container so localhost no longer points to your laptop/desktop/developing machine/server. It points to the container itself where no redis is running. So it will never connect. You need to point to the other container.
For this, you should be using some-redis (the name of the container) instead of localhost. In Redis Commander click more and add server to add a new connection
But this will not work unless both containers are running inside the same network.
You need to create first a new docker network
docker network create redis
And then run your containers using this parameter --network=redis
More about docker network here
More about docker run with networks here

Related

How to setting RabbitMQ?

I just install RabbitMQ in my computer and want to run demo for sending message but it doesn't work. According to documentation the reason may because the broker was started without enough free disk space. And when I check RabbitMQ Management Dashboard, it show my free disk space only 46kb (by default it needs at least 200 MB free). According to documentation I need to change disk_free_limit.
From this documentation I have to create configuration file by myself and put it in C:\Users\User\AppData\Roaming\RabbitMQ. The documentation give an example script for configuration. I change the setting for disk_free_limit.absolute, restart computer (I don't know how to restart RabbitMQ service in windows). But when I check the RabbitMQ Management Dashboard the disk space still 46kb.
I highly recommend the usage of containers for running services like RabbitMQ to avoid problems like the ones you are having at the moment.
I usually use this dockerfile
FROM rabbitmq:3-management
RUN echo '[rabbitmq_management,rabbitmq_management_visualiser,rabbitmq_amqp1_0].' > enabled_plugins
RUN rabbitmq-plugins enable rabbitmq_amqp1_0
For running it
docker build -t my-rabbit .
docker run -it --rm --name rabbitmq -p 5672:5672 -p 15672:15672 my-rabbit:latest
If you never played with docker before, please read this.

Tekton sidecar: docker daemon failing to start

I have a Tekton pipeline that builds and pushes a Docker image to a private repository. The task that handles this uses a DinD sidecar. Originally, it worked just fine, but it's started failing with the error Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?. This was an intermittent error at first, but now it seems to be happening every time I try to run the pipeline. I tried making it wait until it can connect to the daemon, in case it was a timing issue, but it ends up just waiting forever. What might be preventing the Docker daemon from starting, or preventing the task from connecting to it?
Older Docker-DIND images used to create that socket file, a while ago. Nowadays, you would have to use a TCP socket.
See TektonCD samples to patch your Tasks: https://github.com/tektoncd/catalog/blob/main/task/docker-build/0.1/docker-build.yaml

Dynamically created Jenkins Slave using Jenkins Docker Plugin get removed in the middle of Job execution

I am using Jenkins-Docker-Pluginhttps://wiki.jenkins.io/display/JENKINS/Docker+Plugin to dynamically create containers and use them as Jenkins Slaves. This is working fine for some jobs. However for some longer running jobs (10mins >) docker container get removed in midway. Making job failed.
I have tried increasing various timeout options in plugin configuration, However no result. Can anyone please help.
I know I am quite late to post answer here. I am able to get the root cause of the issue. Problem was using two Jenkins instance with same Jenkins Home Directory. Seems Jenkins Docker plugin runs daemon to kill docker container associated with Jenkins Master. As we are running two Jenkins instance with same Jenkins Home directory (Copy of It) Docker containers started for CI work get deleted due to daemon of each other.

How to test throughput of application using rabbitmq?

I have application that uses rabbitmq to queue messages for other parts of ecosystem. I would like to do some performance testing and tuning, but just on my part (the program). So I guess I would like to somehow "mock" away the rabbitmq server, but without changes to my application.
Is there something like dummy rabbitmq server that just accepts all messages and throws them away immediately? Or can I configure actual rabbitmq in that way?
I was using local docker image for the performance test. You can run it with the command:
docker run -d -p 8081:15672 rabbitmq:3-management
You can access management gui on localhost:8081, default username and password is guest/guest
After you are done running a performance test you can purge queue. You do that in Queues>your queue>Purge
PS: Port can be anything you want, just change 8081 in the docker command :)

Google Cloud SSH Server: We are unable to connect to the VM on port 22

I am very new to Google Cloud Platform and was trying to restart my VM instance. I entered $ sudo poweroff into my SSH console, as suggested by https://cloud.google.com/compute/docs/instances/stopping-or-deleting-an-instance#stop_an_instance
and the console did not return anything. Afterwords I started the VM instance again and the SSH console started returning the message "We are unable to connect to the VM on port 22.".
I have a snapshot of my root disk, but I would really like my instance to be running properly again.
When you run either sudo poweroff or sudo shutdown -h now, your VM will shutdown right away. This involves flushing any in-memory buffers for disks back to the disks so that you do not lose any unflushed data.
Since you're initiating this command over a ssh session, you will not be able to look at any shutdown messages over ssh while the instance is shutting down (since the network service on the VM will also be brought down).
You can use gcloud compute instances list or gcloud compute instances describe VM_NAME commands to find out the status of the VM.
If it says RUNNING, it means the instance is running and you will be able to ssh to the VM. If it says TERMINATED, it means the instance was shutdown/terminated and you will not be billed for this instance.