I am coverting my infra. to containers. I have a couple daemons that right now live in rc.local but I want to do this the docker way
here are the commands:
sudo /usr/bin/pt-kill --rds --match-command Query --victims all --match-user phppoint --daemonize --busy-time 30 --kill --print h=db-1,u=master,p=password,P=3306
sudo /usr/bin/pt-kill --rds --match-command Query --victims all --match-user phppoint --daemonize --busy-time 30 --kill --print h=db-2,u=master,p=password,P=3306
What is the proper way to do this via docker?
2
Answers
As mentioned in "How to use Percona Toolkit in a Docker container?", you might need to build your own image, starting from this Dockerfile
The thread mentions The docker image under perconalab (
perconalab/percona-toolkit
) seems to be the same but isn’t.Maybe
perconalab/pmm-client
is a better option.AFAIK Percona doesn’t provide an official Docker image for the toolkit but, as suggested by @VonC in his answer as well, you could try using the
Dockerfile
provided in their Github repository, it will give you a base image with the necessary tools installed, includingpt-kill
. To runpt-kill
, you will need to provide the necessary command when running your docker container, or extend the image by including aCMD
in yourDockerfile
with the necessary information. For reference, I build the aforementionedDockerfile
:And was able to using
pt-kill
against a local docker based MySQL database running the following command from my terminal:I tested it running the following sentence from MySQL Workbench:
Which produces the following output from
pt-kill
:The way in which this container could be run will depend on your actual infrastructure.
I assume by the existence of the
--rds
flag in your command that you are connecting to an Amazon RDS instance.You have many ways for running containers in AWS (see for instance this blog entry, for naming some of them).
In your use case probably the way to go would be using ECS running over EC2 compute instances (the Fargate serverless option doesn’t make sense this time), or even EKS, although I think it would be overkill.
You could provision an EC2 instance, install
docker
, and deploy locally your containers as well, but probably it would a less reliable solution than using ECS.Just in case, and the same applies if running your containers from an on-premise machine, you will need to launch the containers at startup. In my original answer I stated that in the end you probably will need to use
rc.local
orsystemd
to run your container, perhaps by invoking an intermediate shell script, that will launch the actual container usingdocker run
, but thinking about it I realized that the dependency with the docker daemon – it should be running to run your container – could be a problem. Although some kind of automation could be required, consider running your container indicatingalways
orunless-stopped
as the--restart
policy.As you suggested, you could use
docker-compose
for defining both daemons too. The followingdocker-compose.yaml
file could be of help:We are building the docker image in compose itself: it assumes the existence of the mentioned Percona toolkit
Dockerfile
in the same directory in which thedocker-compose.yaml
file is located. You can build the image and publish it to ECR or wherever you see fit and use it in yourdocker-compose.yaml
file as an alternative if you prefer:In order to reuse as much code as possible, the example uses
extension
fragments, although of course you can repeat the service definition if necessary.Note as well that we get rid of the
--daemonize
option in the command definition.In any case, you will need to configure your security groups to allow communication with the RDS database.
Having said all that, in my opinion, your current solution is a good one: although especially using ECS could be a valid solution, probably provisioning a minimal EC2 instance with the necessary tools installed could be a cheaper and simple option than running them in containers.