TigerGraph is my graph database and graph analytics platform of choice as it is fast, scalable, and has an active open-source community. I regularly make use of TigerGraph locally due to my location not having nearby TigerGraph Cloud servers.
A base image of Ubuntu 16.04 is used使用Ubuntu 16.04的基本映像
All required software such as tar, curl, etc. are installed安装了所有必需的软件,例如tar,curl等。
Optional software such as emacs, vim, wget, etc. are installed安装了可选软件,例如emacs,vim,wget等。
GSQL 101 and 102 tutorials and the GSQL Algorithms library is downloaded已下载GSQL 101和102教程以及GSQL算法库
An SSH server, REST++ API, and GraphStudio are the 3 notable ports which can be exposed and used to communicate with the serverSSH服务器,REST ++ API和GraphStudio是3个值得注意的端口,可以公开并用于与服务器通信
The total image is close to a 1.8–2.0GB download (version dependent) which puts considerable strain on bandwidth — especially with resource-sensitive use cases like CI/CD. Another notable point is that all one needs to make use of TigerGraph is a GSQL socket connection which can be interfaced with by tools such as Giraffle and pyTigerGraph.
I’ve identified two large sources of bloat which are:
我发现了两个主要的of肿来源:
The optional and unnecessary software e.g. vim and GSQL Tutorial 101可选和不必要的软件,例如vim和GSQL教程101
GraphStudio and binaries not necessary for the minimal operation of TigerGraph Developer EditionTigerGraph Developer Edition的最小操作不需要GraphStudio和二进制文件
剥离TigerGraph图像 (Stripping the TigerGraph Image)
I’ve replaced the base image ubuntu:16.04 with Bitnami’s MiniDeb image in order to shave off a few megabytes of unnecessary space. This runs Debian Jessie.
The next step was to remove unnecessary binaries installed during the apt-get stage of the official image. I’ve kept Vim as the only command-line text editor but binaries such as wget, git, unzip, emacs, etc. are no longer installed.
During the TigerGraph installation, the hardware requirements are strictly enforced and the installation will fail if they are not met. Since I want DockerHub runners to automatically build and push my image, I hacked the check such that the low-resource runners can continue to build the image.
This is done by replacing the os_utils binary with my version, which makes the check_cpu_number() and check_memory_capacity() functions more lenient. This binary can be found under:
This has already reduced the bloat by around 400MB and my DockerHub image reports a compressed size TigerGraph 3.0.0 of 1.52GB (I did notice that downloading these layers indicates that it comes to around 1.62GB).
Note: I have attempted to haphazardly delete GraphStudio binaries but this fails the gadmin start script so there will have to be more meticulous adjustments made in order to remove more from TigerGraph, e.g editing the gadmin Python scripts.
The SSH server is started by running /usr/sbin/ssh .
通过运行/usr/sbin/ssh启动SSH服务器。
The container is kept alive by running thetail command as user tigergraph. What this does is constantly read output from /dev/null which is also why the container’s STDOUT is empty.
ENTRYPOINT /usr/sbin/sshd && su - tigergraph bash -c "/home/tigergraph/tigergraph/app/cmd/gadmin start all && tail -f /dev/null"
A very simple but valuable change!
一个非常简单但有价值的更改!
使用卷在启动时运行GSQL脚本 (Run GSQL Scripts on Startup Using Volumes)
Something that the TigerGraph Docker Image lacks (which other database images such as MySQL, MariaDB, and PostgreSQL has) is a directory named something along the lines of docker-entrypoint-init.d where a user can bind database scripts to run at startup e.g. for schema creation or database population.
There are various ways to go about this but I’ve chosen a fairly simple way of implementing this by adding the following line between the gadmin and tail command:
The for file in /docker-entrypoint-initdb.d/*.gsql; do line will start a for-each loop of all the files ending with the gsql extension in the entry point folder.
for file in /docker-entrypoint-initdb.d/*.gsql; do的for file in /docker-entrypoint-initdb.d/*.gsql; dofor file in /docker-entrypoint-initdb.d/*.gsql; do line将启动入口点文件夹中所有以gsql扩展名结尾的文件的for-each循环。
The su tigergraph bash -c line will run the GSQL command on the file given by the for-each loop.
su tigergraph bash -c行将在for-each循环给定的文件上运行GSQL命令。
By appending || continue, the container nor the loop will stop if the script failed to execute.
通过附加|| continue|| continue ,容器也不如果脚本未能执行循环将停止。
This will most likely look neater if placed into an entrypoint.sh but this is up to you! The final result now looks something like this:
如果将其放置在entrypoint.sh则看起来更整洁,但这取决于您! 现在,最终结果如下所示:
将日志路由到STDOUT (Routing logs to STDOUT)
In order to figure out where the logs belong, one can run gadmin log which will return something along the lines of
I’m mostly interested in the admin logs so I will change the tail command to read from /home/tigergraph/tigergraph/log/admin/ADMIN.INFO instead of /dev/null.
Now anything written to the admin logs will be piped to the container’s logs automatically. The final product from all three steps are now:
现在,写入管理日志的所有内容都将自动通过管道传递到容器的日志中。 这三个步骤的最终产品现在是:
将Docker Compose与TigerGraph一起使用 (Using Docker Compose with TigerGraph)
Note that I have added a health check which calls the REST++ echo endpoint every 5 seconds to determine if the container is healthy or not. If you use the official image, you would need to SSH into the container to manually start all services:
Note that I have added a health check which calls the REST++ echo endpoint every 5 seconds to determine if the container is healthy or not. This is useful for many applications and, in my use-case, is used to check if the container is ready during integration testing before starting the tests.
Inspected the official Dockerfile,检查了官方的Dockerfile,
identified and removed obvious unnecessary files,确定并删除了明显的不必要文件,
built a slimmer version of the TigerGraph image saving close to 500MB of storage space,构建了更薄的TigerGraph图像版本,可节省近500MB的存储空间,
modified the ENTRYPOINT to add additional automation to the container, and
修改了ENTRYPOINT以向容器添加其他自动化功能,并且
used Docker Compose to run this image.使用Docker Compose运行该映像。
If you have any suggestions or thoughts on ways to further reduce the size of the image, then leave a comment, issue, or fork and give a pull request on the GitHub repository for the code in this article. If you would like to see more Docker-related guides for building custom setups for databases such as JanusGraph then leave a comment below.
You can find these images on Docker Hub, and I will continue to update this as new versions of come out or until TigerGraph makes an official slimmer version.
If you would like to join the TigerGraph community and contribute, or start awesome projects and get a deeper look into what’s coming for TigerGraph, then join us on the following platforms: