I have a Memgraph installed using docker. I didn't use Memgraph Platform docker image, so I don't have a Memgraph Lab.
I have data in .cypherl format. How can I import it into Memgraph?
The exact procedure/command depends on your operating system. If you are using Linux or macOS your command would be:
docker run -i --entrypoint=mgconsole memgraph/memgraph-platform --host HOST < queries.cypherl
If you are running Docker under Windows then the command is:
cmd.exe /c "docker run -i --entrypoint=mgconsole memgraph/memgraph-platform --host HOST < queries.cypherl"
Be sure to replace HOST with valid IP of the container and to define the correct Memgraph Docker image you are using as well as the correct path to the file.
Related
I installed oracle db version 19c in my docker environment with the following command:
docker run --name oracle19c --network host -p 1521:1521 -p 5500:5500
-v /opt/oracle:/u01/oracle oracle/database:19.3.0-ee
Then I connect to it with:
docker exec -ti oracle19c sqlplus system/oracle#orclpdb1
SQL>
Then I setup my database. Afterwards I want to import dummy data from a tbl file so I exit sqlplus and I use the command:
sqlldr userid=system control=/home/userhere/sql_loader/control.ctl log=sf1customer.log
and get sqlldr: not found
I don't have much experience with Docker, but my research leads to me to believe that SQL *Loader does not come with the docker image. However, I do not know how to extend the image or where exactly I would call SQL *Loader even if I did. I am on a Ubuntu server and any help would be appreciated.
SQL*Loader is in the image - but the docker container is separate from your host OS, so ubuntu doesn't know any of the files or commands inside it exist. Any commands inside the container should be run as docker commands. If you try this, it should connect to your running container and print the help page:
docker exec -ti oracle19c sqlldr
Since you're running this command on the docker container, sqlldr doesn't have access to any of your host OS's files unless you specifically granted them to the container. But good news - when you started the database with docker run, that's what the -v /opt/oracle:/u01/oracle part of the command did - it mapped /opt/oracle on your Ubuntu filesystem to /u01/oracle in the docker container. So any files that you put in /opt/oracle will be available in the container under /u01/oracle.
So you'll need to do a couple things:
Your control.ctl file, log file, and whatever data file you're using need to be accessible to the container. Either move them to /opt/oracle or shutdown your database container and restart it with something like -v /home/userhere/sql_loader:/u01/oracle in the command.
You might also need to edit your control.ctl file to make sure that it doesn't reference any file paths on your host OS. Either use relative paths (./myfile.csv) or absolute paths with the container's filesystem (/u01/oracle/myfile.csv)
Now you should be able to run sqlldr on the container, and it should be able to access your data files.
docker exec -ti oracle19c sqlldr userid=system control=/u01/oracle/control.ctl log=/u01/oracle/sf1customer.log
Edit: Oh, I should mention - as an alternative, if you download and install the Oracle Instant Client in Ubuntu, you could run sqlldr locally in Ubuntu, and connect to the docker container over the network as a "remote" database:
sqlldr system#localhost:1521/orclpdb1 control=/home/userhere/sql_loader/control.ctl log=sf1customer.log
That way you don't have to move your files anywhere.
I try to run docker in bash ubuntu on windows. But every time I get this message
"Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?". If i run it in powershell - it work. Can somebody help?
Connecting to the docker deamon requires some privilidges that you don't have when starting the bash terminal.
You can however use the docker command terminal which will allow you to interact with the docker deamon.
Found the solution on this post: https://blog.jayway.com/2017/04/19/running-docker-on-bash-on-windows/
Connect Docker on WSL to Docker on Windows
Running docker against an engine on a different machine is actually quite easy, as Docker can expose a TCP endpoint which the CLI can attach to.
This TCP endpoint is turned off by default; to activate it, right-click the Docker icon in your taskbar and choose Settings, and tick the box next to “Expose daemon on tcp://localhost:2375 without TLS”.
With that done, all we need to do is instruct the CLI under Bash to connect to the engine running under Windows instead of to the non-existing engine running under Bash, like this:
$ docker -H tcp://0.0.0.0:2375 images
REPOSITORY TAG IMAGE ID CREATED SIZE
There are two ways to make this permanent – either add an alias for the above command, or better yet, export an environment variable which instructs Docker where to find the host engine:
$ echo "export DOCKER_HOST='tcp://0.0.0.0:2375'" >> ~/.bashrc
$ source ~/.bashrc
Now, running docker commands from Bash works just like they’re supposed to.
$ docker run hello-world
Hello from Docker!This message shows that your installation appears to be working correctly.
I have issues with launching docker with docker-compose.
When I run docker-compose -f dev.yml build I following error >
Building postgres
ERROR: Couldn't connect to Docker daemon - you might need to run `docker-machine start default`.
However if I run docker-machine ls machine is clearly up >
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS
default - virtualbox Running tcp://192.168.99.100:2376 v1.12.1
I fixed the error by running eval "$(docker-machine env default)" after which docker-compose -f dev.yml build completes successfully.
My question why did this work, what actually happens and how do I undo it?
Also is this a safe way to fix this? Right now this just my laptop, but these containers are supposed to hit company servers in near future.
I am not super fluent with bash but I been always told not to run eval and especially not to run eval with "
When you run docker commands, the CLI connects to the Docker daemon's API, and it's the API that actually does the work. You can manage remote Docker hosts from your local CLI by changing the API connection details, which Docker stores in environment variables on the client where the CLI runs.
With Docker Machine, your Docker engine is running in a VM, which is effectively a remote machine, so your local CLI needs to be configured to connect to it. Docker Machine knows the connection details for the engines it manages, so running docker-machine env default prints out the details for the default machine. The output is something like this:
$ docker-machine env default
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://172.16.62.130:2376"
export DOCKER_CERT_PATH="/Users/elton/.docker/machine/machines/default"
export DOCKER_MACHINE_NAME="default"
Using eval executes each of those export commands, instead of just writing them to the console, so it's a quick way of setting up your environment variables.
You can undo it and reset the local environment with docker-machine env --unset, which gives you the output for unsetting the environment (so the CLI will try to connect to the local Docker Engine).
This is indeed the expected way to use Docker on a machine that does not natively support Docker, e.g. on Windows or Mac OS X.
The Docker documentation includes this step in its description for using Docker Machine here: https://docs.docker.com/machine/get-started/
What this step does (I suggest you also try this yourself):
Run docker-machine env default.
Take the output of that command and execute it in the current shell session.
If you run docker-machine env default yourself, you will see that it simply suggests to set some environment variables, which allow the Docker commands to find the VM running the Docker daemon. Without these variables set, Docker simply does not know how to communicate with the Docker daemon.
In a server environment (Linux), you will not need Docker Machine, since the Linux kernel natively supports running containers. You only need Docker Machine (a small VM running a Linux kernel) on operating systems that don't natively support running containers.
I am using docker on windows. With the use of kitematic, I have created an ubuntu container. This ubuntu image has postgresql installed on it.
Wondering if there is any possibility to access the postgres configuration files available in the container from the host (windows machine)?
Where exactly does the container store its file system on the host machine?
I hope it would be part of image file with format VMDK.
Please correct me if I'm wrong.
Wondering if there is any possibility to access the postgres configuration files available in the container from the host (windows machine)
That is not how Docker would allow you to modify a file in a container.
For that, you should mount a host (Windows) folder when starting (docker run -v) your container.
See "Mount a host directory as a data volume"
docker run -d -P --name web -v /c/Users/<myACcount>/src/webapp:/opt/webapp training/webapp python app.py
Issue 247 mentions ~/Library/Application Support/Kitematic for App data, and ~/Kitematic "for easy access to volume data".
This question may be similar to other questions already answered, but I could not find any that is specific to OSX.
I'm new to Docker. I'm using Docker Version 1.12.1-beta25 (build: 11807) native support for OSX. I wanted to install a Docker Bamboo remote agent, following the instructions at https://confluence.atlassian.com/bamboo/getting-started-with-docker-and-bamboo-687213473.html. My Bamboo server is running on the host.
When running the Docker container with docker run -e HOME=/root/ -e BAMBOO_SERVER=http://hostname:port/bamboo -i -t atlassian/bamboo-java-agent:latest, it failed with Connecting to http://hostname:port/bamboo refused
The problem seems to be that the container could not access the host's http://hostname:port/bamboo. What do I need to do to get this working?
You may try to use http://172.17.0.1:port to find the host from the container. You find this address with docker inspect 'name'.
Or, you can use -p hostPort:containerPort in the docker run command and yse http://localhost:containerPort as Banboo_server