Next, considering we might need to capture a package sometimes, let's check if we can also see the network status. We see that the PID namespace is shared already by setting -pid container. I don't have an image with the NebulaGraph binary file handy, so I'll leave the exploration to you. Now we can easily do our work since we can see the process, for example, attaching it in the GDB. We can see the metad0 process, which has the PID 1. r-r-r- 1 root root 0 Sep18 07:18 udplite r-r-r- 1 root root 0 Sep18 07:18 softnet_statĭr-xr-xr-x 2 root root 0 Sep18 07:18 stat r-r-r- 1 root root 0 Sep18 07:18 sockstat $ docker run - rm -ti -pid container:nebula-docker-compose_metad0_1 -cap-add sys_admin nicolaka/netshoot bashġ root 0:03. Let's add a few parameters to it and see what happens. $ docker run - rm -ti nicolaka/netshoot bashĪs shown above, this container does not have any NebulaGraph process. Let's see what is going to happen if we run the image. Nicolaka/netshoot latest 6d7e8891c980 2months ago 352MB ![]() Vesoft/nebula-metad nightly 5a78d3e3008f 36hours ago 288MB Vesoft/nebula-console nightly f3256c99eda1 36hours ago 249MB Vesoft/nebula-storaged nightly 5c77dbcdc507 36hours ago 288MB Vesoft/nebula-graphd nightly c67fe54665b7 36hours ago 282MB $ docker pull nicolaka/netshoot $ docker images ![]() Here, we use a community solution from nicolaka/netshoot. If later we find this image not good enough, we can maintain a nebula-debug image and install all the debugging tools we want then. Let's find a well-packed image from Docker Hub. There is no need to build one by ourselves since this is only for demonstration. First of all, we need to have a handy image for debugging. Next, we demonstrate scenario by scenario, from the process namespaces to the network namespaces. doneĬreating nebula-docker-compose_graphd_1. doneĬreating nebula-docker-compose_storaged0_1. doneĬreating nebula-docker-compose_storaged1_1. doneĬreating nebula-docker-compose_storaged2_1. doneĬreating nebula-docker-compose_metad0_1. doneĬreating nebula-docker-compose_metad2_1. $ docker-compose up -dĬreating network "nebula-docker-compose_nebula-net" with the default driverĬreating nebula-docker-compose_metad1_1. After the deployment, we start all the services and check their status as follows. ![]() For a detailed tutorial, see the README file in the repository. Start by deploying a NebulaGraph cluster locally with Docker-Compose, as we mentioned above. In this way, we can view the processes and network namespaces in the original container through the container we use to debug, which has everything we need installed in it. The principle is quite simple: Start a container that shares the same namespaces of the PID/network with the container we are debugging. In fact, there is another way to debug a process inside a container, without breaking the content structure of the container or installing any toolkit in it.Īctually, this technique, the Sidecar mode, is commonly used in the K8S environment. This makes it difficult to locate problems inside the containers because it was cumbersome to install essential toolkit every time to get things done. But to compress the docker image of each NebulaGraph service as much as possible, all the tools commonly used for development are not installed in the Docker images, not even the editor Vim. In the development or testing process, we often use the vesoft-inc/nebula-docker-compose repository to deploy NebulaGraph.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |