I'm using Envoy docker image in docker-compose. Docker is running in Ubuntu, which is running in VM, which is running in Windows 10.
I have been using Envoy 1.14 without any problems. After upgrading image to 1.15, Envoy doesn't start and I'm getting this error:
unable to read file: /etc/envoy/envoy.yaml
line before this one says basically the same:
[critical][main] [source/server/server.cc:101] error initializing configuration '/etc/envoy/envoy.yaml': unable to read file: /etc/envoy/envoy.yaml
My docker-compose part for Envoy is simple:
envoy:
image: envoyproxy/envoy:v1.15-latest
container_name: envoy
restart: always
volumes:
- "~/envoy.yaml:/etc/envoy/envoy.yaml:ro"
If I just change envoyproxy/envoy:v1.15-latest to envoyproxy/envoy:v1.14-latest and do docker-compose down && docker-compose up, everything works fine. Are there any special permissions for config file now? Or is it something during my upgrade process?
Solved in github issue: https://github.com/envoyproxy/envoy/issues/12747#issuecomment-677485704
Solution: change permissions for envoy.yaml (chmod 777 is working fine for me).
Related
While trying to run a MongoDB docker instance with authorization managed by docker-secrets (with files), inspired by this blog post, I kept running into the following error:
2020-07-24T16:25:26.656+0000 E QUERY [js] uncaught exception: Error: couldn't add user: Error preflighting normalization: U_STRINGPREP_PROHIBITED_ERROR :
Setup
Windows machine running docker with a WSL2 backend.
latest mongo image from docker hub (version 4.2.8)
docker secrets to manage the authentication credentials to the MongoDB database
my composer file:
# docker-compose.yml
version: '3.5'
services:
my_db:
image: mongo
command: --auth
environment:
MONGO_INITDB_ROOT_PASSWORD_FILE: /run/secrets/mongodb_root_password
MONGO_INITDB_ROOT_USERNAME_FILE: /run/secrets/mongodb_root_username
secrets:
- mongodb_root_password
- mongodb_root_username
secrets:
mongodb_root_password:
- file: mongodb/.mongodb_root_password
mongodb_root_username:
- file: mongodb/.mongodb_root_username
shell command to deploy docker stack
$ docker stack deploy --compose-file=docker-compose.yml my_db_stack
Problem
Unfortunately, the container kept dying. In the logs, I was able to find the error mentioned above.
It turns out that the problem was caused by Windows-style line endings in the mongodb/.mongodb_root_password and mongodb/.mongodb_root_username files. Those files were created on the Windows host, and then (I assume) were blindly copied to the container.
Solution
Using notepad++ I switched the line endings to Unix-style, which solved the problem.
To switch the line endings, I right-clicked the highlighted portion of the bottom bar in the image below, on Notepad++.
I have a docker-compose file that looks like this
version: "3.7"
services:
app:
stdin_open: true
tty: true
build:
context: .
dockerfile: app.Dockerfile
volumes:
- ${HOST_SAVE_DIRC}:${CONTAINER_SAVE_DIRC}
depends_on:
- postgres
postgres:
image: 'postgres'
environment:
- POSTGRES_DB=${POSTGRES_DB}
- POSTGRES_USER=${POSTGRES_USER}
- POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
- POSTGRES_HOST_AUTH_METHOD=trust
restart: always
expose:
- "5432"
where variables like POSTGRES_USER are entries from a env file. app.Dockerfile looks like
FROM python:3.8.3-slim-buster
COPY src /src/
COPY init.sql .
COPY .env .
COPY run.sh run.sh
COPY requirements.txt .
RUN ls -a
RUN pip install --no-cache-dir -r requirements.txt
The containers are created, then the user is logged into the app container w/ the main function of the program being called - this is when the database calls
From the app container I am attempting to connect to the postgres container via psycopg2. However when I attempt to do so, I receive the following error:
psycopg2.OperationalError: could not connect to server: No route to host
Is the server running on host "postgres" (172.22.0.2) and accepting
TCP/IP connections on port 5432?
using a psycopg2 call that looks like
with psy.connect(host='postgres', port=5432, user='postgres', password='postgres') as conn:
...
the entries of this psycopg2 call match the env file given to the docker-compose file.
My understanding is that Postgres uses port 5432 by default. Also that when docker-compose creates the two containers - it creates a docker network for those containers name DIR_default where DIR is the name of the directory the docker-compose file lives in, where each container can be accessed with using the name listed in the docker-compose file ('postgres' and 'app' in these cases).
Among various tries:
I've checked and the database isn't going down between the container being created and the user being exec'd in.
I've tried various little changes like changing the container names, postgres login info, etc.
I've tried linking the postgres container name explicitly with link: "postgres:postgres".
Other solutions suggested here
Any help would be greatly appreciated! I see no reason why something as simple as this should be occurring, but also here I am.
Edit:
Pinging the Postgres container from the app container appears to be working when running docker exec app ping postgres_container_name. Is this a sign that the Docker network is set up correctly and the issue is something of mine?
Edit 2:
Tried clearing all images and containers, then restarting the Docker daemon and afterwards my PC. No change in either case.
For reference, the ping command looked like
docker exec python-app ping name_given_to_postgres_container
returning various statements which looked like
64 bytes from name_given_to_postgres_container.project_name_default (172.18.0.3): icmp_seq=1 ttl=64 time=0.090 ms
which unless I am mistaken, I believe is signalling a succesful ping.
The top level .env file provided to docker-compose
HOST_SAVE_DIRC=~/python_projects/project_directory/directory_in_project
CONTAINER_SAVE_DIRC=/pdfs
POSTGRES_DB=project_name # same as project_directory
POSTGRES_USER=postgres
POSTGRES_PASSWORD=postgres
POSTGRES_PORT=5432
Here is the requirements.txt file for the Python app as well
certifi==2020.4.5.1
chardet==3.0.4
idna==2.9
psycopg2-binary==2.8.5
read-env==1.1.0
requests==2.23.0
urllib3==1.25.9
Exec-ing into the Postgres container with docker exec -it container_id bash and running psql -U postgres appears to be successful - even with restart: always removed. I can also see the database named in the docker-compose file is also created. I feel confident in saying this container isn't dying spontaneously.
However, hitting the 5432 port on the Postgres container with netcat via nc name_given_to_postgres_container 5432-5433 returns an error similar to the one returned by psycopg2
arxivist_postgres_1 [172.22.0.3] 5433 (?) : No route to host
arxivist_postgres_1 [172.22.0.3] 5432 (postgresql) : No route to host
The same error is also returned with curl. So my guess the issue isn't with the Postgres container directly, psycopg2, or the host-name - but something with the port?
Edit 3:
As a last attempt to fix this project, the full project this post is referring to is posted at this link. If anyone would like to download the repo and try building the docker containers themselves via ./start.sh - that might be just what is needed to find a solution!
I thought I had Docker setup on my machine, which runs Fedora 32. However as I came to realize from this article, setting up Docker on Fedora 32 requires some extra steps I was not previously aware of.
Specifically for this issue, the command listed in the article to add Docker to whitelist Docker on the local network's firewall with the command
sudo firewall-cmd --permanent --zone=FedoraWorkstation --add-masquerade
So I believe the root cause of my issue was simply my app container being blocked from accessing the postgres container by the firewall. Making the above change made the program work finally!
I need to copy a php.ini file that I have (with xdebug enabled) to /bitnami/php-fpm/conf/. I am using a bitnami docker container, and I want to use xdebug to debug the php code in my app. Therefore I must enable xdebug in the php.ini file. The /bitnami/php-fpm container on the repository had this comment added to it:
5.5.30-0-r01 (2015-11-10)
php.ini is now exposed in the volume mounted at /bitnami/php-fpm/conf/ allowing users to change the defaults as per their requirements.
So I am trying to copy my php.ini file to /bitnami/php-fpm/conf/php.ini in the docker-compose.yml. Here is the php-fpm section of the .yml:
php-fpm:
image: bitnami/php-fpm:5.5.26-3
volumes:
- ./app:/app
- php.ini:/bitnami/php-fpm/conf
networks:
- net
volumes:
database_data:
driver: local
networks:
net:
Here is the error I get: ERROR: Named volume "php.ini:/bitnami/php-fpm/conf:rw" is used in service "php-fpm" but no declaration was found in the volumes section.
Any idea how to fix this?
I will assume that your indentation is correct otherwise you probably wouldn't get that error. Always run your yaml's through a lint tool such as http://www.yamllint.com/.
In terms of your volume mount, the first one you have the correct syntax but the second you don't therefore Docker thinks it is a named volume.
Assuming php.ini is in the root directory next to your docker-compose.yml.
volumes:
- ./app:/app
- ./php.ini:/bitnami/php-fpm/conf
I'm new to learning how to use goLang to build microservices. I had a whole project up and running locally, but when I tried deploying it I ran into a problem. The session I was working with (mgo.Dial("localhost")) was no longer working. When I put this into a docker image, it failed to connect to the local host, which makes sense, since the docker image builds it over a new OS (alpine in my case). I was wondering what I should do to get it to connect.
To be clear, when I was researching this, most people wanted to connect to a mongoDB session that is a docker container, I want to connect to a mongoDB session from within a docker container. Also once I'm ready for deployment I'll be using StatefulSet with kubernetes if that changes anything.
For example, this is what I want my program to be like:
sess, err := mgo.Dial("localhost") //or whatever
if err != nil {
fmt.Println("failed to connect")
else {
fmt.Println("connected")
What I tried doing:
Dockerfile:
FROM alpine:3.6
COPY /build/app /bin/
EXPOSE 8080
ENTRYPOINT ["/bin/app"]
In terminal:
docker build -t hell:4 .
docker run -d -p 8080:8080 hell:4
And as you can expect, it says not connected. Also the port mapping is for the rest of the project, not this part.
Thanks for your help!
I think you should not try to connect to the MongoDB server running on your machine. Think about deploying the whole application lateron you want a MongoDB server running together with your service on some cloud or server.
That problem could be solved by setting up an additional container and link it to your Go Web App. Docker compose can handle this. Just place a docker-compose.yml file in the directory you are executing your docker build in.
version: '3'
services:
myapp:
build: .
image: hell:4
ports:
- 8080:8080
links:
- mongodb
depends_on:
- mongodb
mongodb:
image: mongo:latest
ports:
- "27017:27017"
environment:
- MONGODB_USER="user"
- MONGODB_PASS="pass"
Something like this should do it (not tested). You have two services: One for your app that gets build according to your Dockerfile in the directory in which you currently are. Additionally it links to a service called mongodb defined below. The mongodb service is accessible via the service name mongodb.
If your mongoDB server is running in your host machine, replace localhost by you host IP.
docker-compose --version
docker-compose version 1.11.1, build 7c5d5e4
I have secret 'my_secret_data' added to my swarm cluster:
The start of my compose file looks like:
version: "3.1"
secrets:
my_secret_data:
external: true
services:
master:
image: jenkins-master
secrets:
- my_secret_data
ports:
- "8080:8080"
- "50000:50000"
'docker stack deploy' continually gives the error:
secrets Additional property secrets is not allowed
I have followed how do you manage secret values with docker-compose v3.1? to the letter as far as I can tell and have the correct versions installed but keep getting the above error. Any help greatly appreciated.
Change compose file version to latest version.
In short, version '3' is not resolved to the latest '3.x' version. Find what the latest version is here https://docs.docker.com/compose/compose-file/#compose-and-docker-compatibility-matrix
The "Additional property secrets is not allowed" error can be caused either by:
running Docker Engine < 1.13.1, or
using a compose file version number < '3.1' in a docker-compose file such as docker-compose.yml or docker-cloud.yml
If you are experiencing this problem confirm that both are correct.
This also applies to other Docker interfaces and tools.
For examples, in Portainer, yml with secrets lines pasted into the Create Stack dialog should begin with the line version: '3.1' or you will encounter the same error -- even with an up-to-date Docker Engine 1.13.1+.
In my case, Service: had an extra tab prior. Moment I removed tab prior to it, it worked.