The YottaDB Docker container can be found here.
A working Docker installation on your platform of choice.
NOTE: You must have at least docker 17.05 as multi-stage builds are used within the docker file.
Docker Pull Command¶
docker pull yottadb/yottadb
The docker image is built using the ydb script that gives the user some sane defaults to begin exploring YottaDB. This is not meant for production usage.
The commands below assume that you want to remove the docker container after running the command, which means that if you don't mount a volume that contains your database and routines they will be lost. If you want the container to persist, remove the –rm parameter from the docker command.
Volumes are also supported by mounting to the /data directory. If you want to mount the local directory ydb-data into the container to save your database and routines locally and use them in the container in the future, add the following command line parameter before the yottadb/yottadb argument:
This creates a ydb-data directory in your current working directory. This can be deleted after the container is shutdown/removed if you want to remove all data created in the YottaDB container (such as your database and routines).
You may need to enable Docker by giving it the appropriate permissions. An
ls -la /var/run/docker.sock will show you what group can access the socket. Make sure to add your user to that group. Otherwise, depending on the permissions of the docker socket, you may need to use
sudo docker instead of
Running a pre-built image¶
docker run --rm -it yottadb/yottadb # you can add a specific version after a ":" if desired
Build the image
docker build -t yottadb/yottadb:latest .
Run the created image.
docker run --rm -it yottadb/yottadb:latest
YottaDB related logs should persist after a pod stops or is evicted. These logs contain very important information that help in diagnosing the problem. Refer to https://kubernetes.io/docs/concepts/cluster-administration/logging/ for information on logging in Kubernetes.
Use YottaDB's Instance Freeze Capability. Without instance freeze, if journaling cannot be continued due to limited disk-space or any other reasons, it is turned off automatically but the database is allowed to continue updating. This is fine if the situation is fixed and journaling is turned back on, but if the pod is lost then data recovery is problematic.
Use a preStop hook to stop processes accessing YottaDB gracefully when a pod needs to be stopped.
Improve security by running all YottaDB processes in a single pod/multiple container set-up, rather than multiple pod/single container. The security issues are summarized here: https://serverfault.com/questions/1054724/ipc-between-multiple-pods-on-same-kubernetes-node.