I've started ArangoDB from a docker container with -e ARANGO_NO_AUTH=1 and mapped the volumes /var/lib/arangodb3 and /var/lib/arangodb3-apps to my local drive. Next i wanted to create a new app but when i click Services from the web interface i get following error:
GET http://127.0.0.1:8529/_db/_system/_admin/aardvark/foxxes 400 (Bad Request)
Do i need to be authenticated to do that or is this a docker problem? There are no errors in the log.
Im using the latest version from docker hub in this case version 2.8.9
Docker command:
docker run -e ARANGO_NO_AUTH=1 -p 8529:8529 --name arangodb-i -v /home/me/projects/dbs/arango/db:/var/lib/arangodb3 -v /home/me/projects/dbs/arango/apps:/var/lib/arangodb3-apps arangodb/arangodb
ArangoDB Info:
INFO ArangoDB 3.0.0 [linux] 64bit, using VPack 0.1.30, ICU 54.1, V8 5.0.71.39, OpenSSL 1.0.1k 8 Jan 2015
The error message comes in both Chrome and Firefox but not in curl.
This error does not occur when i install arangodb in ubuntu, only when i run it with docker.
It seems like the docker image needs the Authorization header set, but because of the ARANGO_NO_AUTH it doesn't seem to matter what it's set to:
docker run --rm -e ARANGO_NO_AUTH=1 -p 8529:8529 arangodb/arangodb:3.0.0
curl -H "Authorization: foo bar" http://127.0.0.1:8529/_db/_system/_admin/aardvark/foxxes
[{"mountId":"81","mount":"/_api/gharial","name":"gharial","description":"ArangoDB Graph Module","author":"ArangoDB GmbH","system":true,"development":false,"contributors":[{"name":"Michael Hackstein","email":"m.hackstein#arangodb.com"}],"license":"Apache License, Version 2.0","version":"3.0.0","path":"/usr/share/arangodb3/js/apps/system/_api/gharial/APP","config":{},"deps":{},"scripts":{}},{"mountId":"75","mount":"/_admin/aardvark","name":"aardvark","description":"ArangoDB Admin Web Interface","author":"ArangoDB GmbH","system":true,"development":false,"contributors":[{"name":"Heiko Kernbach","email":"heiko#arangodb.com"},{"name":"Michael Hackstein","email":"m.hackstein#arangodb.com"},{"name":"Lucas Dohmen","email":"lucas#arangodb.com"}],"license":"Apache License, Version 2.0","version":"3.0.0","path":"/usr/share/arangodb3/js/apps/system/_admin/aardvark/APP","config":{},"deps":{},"scripts":{}}]
This also works:
curl --user foo:bar http://127.0.0.1:8529/_db/_system/_admin/aardvark/foxxes
The 2.8.9 image does not have this issue.
Related
I've been using for years a containerized version of a web-application on my development laptop. Usually I do something like
docker run -it -d --rm -h app.localhost my-app
and, having added app.localhost to my hosts file, going to http://app.localhost everything works. Yesterday an update came for docker and I'm no longer able to do that. Running the image with the same command line options and trying to connect to the application I get a browser error page and checking the logs in the container shows no request at all got to the web server. Running curl http://app.localhost in a terminal works fine, and I've been able to fix the problem changing the my command line options to
docker run -it -d --rm -p 80:80 -h app.localhost my-app
i.e. explicitly exposing port 80.
Can anyone explain what went wrong? And why would curl and my web browser behave differently?
Edit: to clarify: I'm referring to an update of the docker packages for my OS (Ubuntu 18 if that matters).
I'm trying to get started with Hasura GraphQL engine running locally on OSX in Docker and connecting to an existing database but I am having trouble finding the container or the Hasura console.
Here's what I have:
docker -v
Docker version 19.03.5, build 633a0ea
docker-compose -v
docker-compose version 1.25.4, build 8d51620a
docker images
hasura/graphql-engine v1.0.0
hasura version
INFO hasura cli version=v1.0.0
Here's my start script (docker-run.sh) which sets up the port and environment variables for Hasura:
#!/bin/bash
docker run -d -p 8080:8080 \
-e HASURA_GRAPHQL_DATABASE_URL=postgres://someuser:somepassword#host.docker.internal:5432/somedb \
-e HASURA_GRAPHQL_ENABLE_CONSOLE=true \
hasura/graphql-engine:latest
Running ./docker-run.sh returns a 64 char hex string, which I assume to be the container ID, but I cannot see a container when I run docker ps, and nothing loads on http://localhost:8080/console.
What am I missing?
UPDATE 1
I can see the container when I run docker ps -a - it has a status of exited(1) (which means application error).
I can see in the logs:
{"path":"$","error":"pgcrypto extension is required, but the current user doesn’t have permission to create it. Please grant superuser permission, or setup the initial schema via https://docs.hasura.io/1.0/graphql/manual/deployment/postgres-permissions.html","code":"postgres-error"}
I have followed the instructions for setting up the initial schema but the result of running ./docker-run.sh has not changed.
UPDATE 2
I did not realise that the pgcrypto extension had to be installed on the specific database. Now that I have done so, the logs look healthy - although I am still unable to access the console when I run hasura console.
Here's my config.yaml:
endpoint: http:localhost:8080
...and the resulting error:
FATA[0001] version check: failed to get version from server: failed making version api call: Get http:localhost:8080/v1/version: http: no Host in request URL
Again, what am I missing?
UPDATE 3
Changed config.yaml...
endpoint: http://localhost:8080
Whoops (blush).
OK, it's working :)
I read the blog: https://www.rubix.nl/blogs/tibco-monitoring-docker-how-create-instantiate-and-start-tibco-businessworks-container-edition
The blog entry is very interesting. Unfortunately, it does not work for me. My Tibco service does not connect to the monitoring.
Here is some data:
Bwce Version: 2.3
Bwce Mon Version: 2.4
Log entry from my Tibcoservice: Failed to register with Monitoring
application - response code [400] and Reason Phrase [Bad Request]
Log entry from my bwce-mon:
INFO:{"host":"172.17.0.4","port":"8090","instanceName":"6866a20e7bd6","appName":"6866a20e7bd6"
WARN : Container is not running for (host, port):(172.17.0.4, 8090). Please register running container
Docker run command for Tibcoservice: docker run -d -p 7575:7575 --link bwceadmin --name helloworld -e EMS_URL=tcp://ubdev-ws-003:7223 -e EMS_QUEUE=docker.queue -e BW_APP_MONITORING_CONFIG='{"url":"http://bwceadmin:8080"}'
helloworld:1.0.0
Docker run command for bwce-mon: docker run -p 8080:8080 -e persistence_DB="dockerpostgres" -e
DB_URL="postgres://postgres:#172.17.0.2:5432/postgres" -e
PERSISTENCE_TYPE=postgres --name bwceadmin bwcemon:2.4.0
Do you have any idea why this did not work for me?
I didn't write the blog post, but I think your issue might be in the configuration of the property "BW_APP_MONITORING_CONFIG".
Can you check if you can access the URL http://bwceadmin:8080? If you can't access that, the issue is most likely to do with the configuration of that property.
To find the setting for that URL, you'll need to know the IP address of the container running your app:
docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' <your container name>
After getting the IP address (like 10.100.22.1), you can start a new BWCE app and add a property for the monitoring URL:
BW_APP_MONITORING_CONFIG='{"url":"http://10.100.22.1:8080"}'
Just installed and tried to start Solace 8.5 community edition in Docker. Had successfully been running 8.4 for weeks. 8.5 attempts to start and then dies with following error:
2017-09-11T18:55:36+0000 ip-10-97-56-158 root[178]: /usr/sw
adCmnDiskTrans.cpp:150 (ADMANAGER - 0x00000001) main(0)#dataplane(11)
FATAL file /usr/sw/internalSpool/softAdb/backingStore actual size(536870912) !=
expected size(805306368)
Rolling back to 8.4 runs fine. Docker command is:
docker run -v /data/vmr/adb:/usr/sw/adb -v /data/vmr/internalSpool/softAdb:/usr/sw/internalSpool/softAdb -v /data/vmr/jail:/usr/sw/jail -v /data/vmr/var:/usr/sw/var -v /data/vmr/internalSpool:/usr/sw/internalSpool -v /data/vmr/diags:/var/lib/solace/diags -d --network=host --uts=host --shm-size=4g --ulimit core=-1 --ulimit memlock=-1 --ulimit nofile=2448:38048 --cap-add=IPC_LOCK --cap-add=SYS_NICE --env 'username_admin_globalaccesslevel=admin' --env 'username_admin_password=admin' --name=solace8.5 solace-app:8.5.0.1008-community
It does not work because there is no upgrade path for the community edition VMR.
If you wish to migrate any message-vpn configs, generally there is a good chance of success by backing it up in CLI:
solace-old> show current-config message-vpn <name> > /configs/vpn-config.txt
and importing it in the newer release:
solace-new> source script /configs/vpn-config.txt stop-on-error
Ref: http://docs.solace.com/System-and-Software-Maintenance/Generating-CLI-Config-Sequences.htm
Note that you should empty out the volumes; don't try to use the same volumes that retained files from the older VMR on the newer VMR.
I'm brand new to both TeamCity and Docker. I'm struggling to get a Docker container with TeamCity running and usable on my local machine. I've tried several things, to no avail:
I installed Docker for Mac per instructions here. I then tried to run the following command, documented here, for setting up teamcity in docker:
docker run -it --name teamcity-server-instance \
-v c:\docker\data:/data/teamcity_server/datadir \
-v c:\docker\logs:/opt/teamcity/logs \
-p 8111:8111 \
jetbrains/teamcity-server
That returned the following error: docker: Error response from daemon: Invalid bind mount spec "c:dockerdata:/data/teamcity_server/datadir": invalid mode: /data/teamcity_server/datadir.
Taking a different tack, I tried to follow the instructions here - I tried running the following command:
docker run -it --name teamcity -p 8111:8111 sjoerdmulder/teamcity
The terminal indicated that it was starting up a web server, but I can't browse to it at localhost, nor at localhost:8111 (error ERR_SOCKET_NOT_CONNECTED without the port, and ERR_CONNECTION_REFUSED with the port).
Since the website with the docker run command says to install Docker via Docker Toolbox, I then installed that at the location they pointed to (here). I then tried the
docker-machine ip default
command they suggested, but it didn't work, error "Host does not exist: "default"". That makes sense, since the website said the "default" vm would be created by running Docker Quickstart and I didn't do that, but they don't provide any link to Docker Quickstart, so I don't know what they are talking about.
To try to get the IP address the container was running on, I tried this command
docker inspect --format='{{.Name}} - {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' $(docker ps -aq)
That listed the names of the running containers, each followed by a hyphen, then nothing. I also tried
docker ps -a
That listed running contaners also, but didn't give the IP. Also, the port is blank, and the status says "exited (130) 4 minutes ago", so it doesn't seem like the container stayed alive after starting.
I also tried again with port 80, hoping that would make the site show at localhost:
docker run -it --name teamcity2 -p 80:80 sjoerdmulder/teamcity
So at this point, I'm completely puzzled and blocked - I can't start the server at all following the instructions on hub.docker.com, and I can't figure out how to browse to the site that does start up with the other instructions.
I'll be very grateful for any assistance!
JetBrains now provides official docker images for TeamCity. I would recommend starting with those.
The example command in their TeamCity server image looks like this
docker run -it --name teamcity-server-instance \
-v <path to data directory>:/data/teamcity_server/datadir \
-v <path to logs directory>:/opt/teamcity/logs \
-p <port on host>:8111 \
jetbrains/teamcity-server
That looks a lot like your first attempt. However, c:\docker\data is a Windows file path. You said you're running this on a mac, so that's definitely not going to work.
Once TeamCity starts, it should be available on port 8111. That's what -p 8111:8111 part of the command does. It maps port 8111 on your machine to port 8111 in the VM Docker for Mac creates to run your containers. ERR_CONNECTION_REFUSED could be caused by several things. Two most likely possibilities are
TeamCity could take a little while to start up and maybe you didn't give it enough time. Solution is to wait.
-it would start the TeamCity container in interactive mode. If you exit out of the terminal window where you ran the command, the container will also probably terminate and will be inaccessible. Solution is to not close the window or run the container in detached mode.
There is a good overview of the differences between Docker for Mac and Docker Toolbox here: Docker for Mac vs. Docker Toolbox. You don't need both, and for most cases you'll want to use Docker for Mac for testing stuff out locally.