Can't Access Web (Flask) Application from Google Cloud Platform's VM SSH Link - docker-compose

My goal is to run a docker-compose cluster on a VM from Google Cloud Platform. I have successfully installed docker and docker-compose:
$ uname -a
Linux instance-6 4.15.0-1083-gcp #94~16.04.1-Ubuntu SMP Sat Sep 5 22:53:03 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ docker -v
Docker version 19.03.13, build 4484c46d9d
$ docker-compose -v
docker-compose version 1.27.3, build 4092ae5d
I am following the basic tutorial to create a docker-compose cluster using: https://docs.docker.com/compose/gettingstarted/ (Steps #1-#4).
My app.py file is:
import time
import redis
from flask import Flask
app = Flask(__name__)
cache = redis.Redis(host='redis', port=6379)
def get_hit_count():
retries = 5
while True:
try:
return cache.incr('hits')
except redis.exceptions.ConnectionError as exc:
if retries == 0:
raise exc
retries -= 1
time.sleep(0.5)
#app.route('/')
def hello():
count = get_hit_count()
return 'Hello World! I have been seen {} times.\n'.format(count)
My requirements.txt file is:
flask
redis
My Dockerfile is:
FROM python:3.7-alpine
WORKDIR /code
ENV FLASK_APP app.py
ENV FLASK_RUN_HOST 0.0.0.0
RUN apk add --no-cache gcc musl-dev linux-headers
COPY requirements.txt requirements.txt
RUN pip install -r requirements.txt
EXPOSE 5000
COPY . .
CMD ["flask", "run"]
And, my docker-compose.yml is:
version: '3'
services:
web:
build: .
ports:
- "5000:5000"
redis:
image: "redis:alpine"
Running docker-compose up gives me the correct output. One of the outputs points to where the web_1 is running.
$ docker-compose up
...
web_1 | * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)
...
After pressing the link http://0.0.0.0:5000/, GCP doesn't connect. It tries to go to the URL: https://ssh.cloud.google.com/devshell/proxy?authuser=2&devshellProxyPath=%2F&port=5000&environment_name&environment_id, but then it gives the error: 500. That’s an error. There was an error. Please try again later. That’s all we know.
Going to the external IP address and putting in port 5000 also doesn't return anything. (http://IPAddress:500)
I checked the ports:
$ sudo docker-compose ps
Name Command State Ports
composetest_redis_1 docker-entrypoint.sh redis ... Up 6379/tcp
composetest_web_1 flask run Up 0.0.0.0:5000->5000/tcp
I'm not sure what the reason it. I'm guessing it is the firewall configuration from GCP. Everything is just the default settings. I also allowed HTTP and HTTPS requests in the Compute Engine VM Instance settings. Would really appreciate more guidance on what to do. Thanks in advance!
See below for full output:
$ sudo docker-compose up
Starting composetest_redis_1 ... done
Starting composetest_web_1 ... done
Attaching to composetest_redis_1, composetest_web_1
redis_1 | 1:C 23 Sep 2020 21:40:27.816 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
redis_1 | 1:C 23 Sep 2020 21:40:27.816 # Redis version=6.0.8, bits=64, commit=00000000, modified=0, pid=1, just started
redis_1 | 1:C 23 Sep 2020 21:40:27.816 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
redis_1 | 1:M 23 Sep 2020 21:40:27.818 * Running mode=standalone, port=6379.
redis_1 | 1:M 23 Sep 2020 21:40:27.818 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
redis_1 | 1:M 23 Sep 2020 21:40:27.818 # Server initialized
redis_1 | 1:M 23 Sep 2020 21:40:27.818 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
redis_1 | 1:M 23 Sep 2020 21:40:27.819 * Loading RDB produced by version 6.0.8
redis_1 | 1:M 23 Sep 2020 21:40:27.819 * RDB age 27 seconds
redis_1 | 1:M 23 Sep 2020 21:40:27.819 * RDB memory usage when created 0.77 Mb
redis_1 | 1:M 23 Sep 2020 21:40:27.819 * DB loaded from disk: 0.000 seconds
redis_1 | 1:M 23 Sep 2020 21:40:27.819 * Ready to accept connections
web_1 | * Serving Flask app "app.py"
web_1 | * Environment: production
web_1 | WARNING: This is a development server. Do not use it in a production deployment.
web_1 | Use a production WSGI server instead.
web_1 | * Debug mode: off
web_1 | * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)

Need to properly allow traffic through that port by:
Creating a firewall rule with a tag
Including that tag in the VM's Network settings
Link here: Network Tags

Related

redis rdb file permission denied in AWS ECS

i have this redis service in my docker compose file
redis:
container_name: redis
image: redis:${VERSION_REDIS}
ports:
- "6379:6379"
networks:
- backend
if i run docker-compose locally, than the redis db is working as intended.
1:M 12 Jun 2022 14:47:51.212 * Running mode=standalone, port=6379.
1:M 12 Jun 2022 14:47:51.213 # Server initialized
1:M 12 Jun 2022 14:47:51.215 * Loading RDB produced by version 6.2.5
1:M 12 Jun 2022 14:47:51.216 * RDB age 728 seconds
1:M 12 Jun 2022 14:47:51.219 * RDB memory usage when created 0.79 Mb
1:M 12 Jun 2022 14:47:51.219 * DB loaded from disk: 0.004 seconds
1:M 12 Jun 2022 14:47:51.220 * Ready to accept connections
The version used is 6.2.5-buster. If i try to use docker-compose to my AWS ECS cluster, every service starts normal but the redis task has the following protocol output:
12.6.2022, 16:32:34 1:M 12 Jun 2022 14:32:34.734 # Failed opening the RDB file crontab (in server root dir /etc) for saving: Permission denied
12.6.2022, 16:32:34 1:M 12 Jun 2022 14:32:34.164 # Failed opening the RDB file zzh (in server root dir /etc) for saving: Permission denied
12.6.2022, 16:32:32 1:M 12 Jun 2022 14:32:32.836 # Failed opening the RDB file root (in server root dir /etc) for saving: Permission denied
12.6.2022, 16:32:32 1:M 12 Jun 2022 14:32:32.646 # Failed opening the RDB file root (in server root dir /etc) for saving: Permission denied
12.6.2022, 16:32:32 1:M 12 Jun 2022 14:32:32.267 # Failed opening the RDB file root (in server root dir /etc) for saving: Permission denied
12.6.2022, 16:32:30 1:M 12 Jun 2022 14:32:30.939 # Failed opening the RDB file backup.db (in server root dir /etc) for saving: Permission denied
12.6.2022, 16:40:47 1:M 12 Jun 2022 14:40:47.168 # Background saving error
i tried to search for solutions, but i am just starting out with container services on AWS. How can i configure my docker-compose file or how to change the permissions inside aws to make redis work? Are there other ways? Thank you. The cluster is running on fargate.

systemd: seems like ExecStop script is executed immediately after the start command is run

I am trying to start a docker-compose project as a systemd service on RHEL 7. Here is my systemd script (/etc/systemd/system/wp.service):
[Unit]
Description=wp service with docker compose
Requires=docker.service
After=docker.service
[Service]
EnvironmentFile=/home/ec2-user/projects/wp/project-dir/vars.env
WorkingDirectory=/home/ec2-user/projects/wp/project-dir
# ExecStartPre=/usr/bin/docker-compose down
ExecStart=/usr/bin/docker-compose up -d --build --remove-orphans
# ExecStop=/usr/bin/docker-compose down
[Install]
WantedBy=multi-user.target
When I execute the following command:
sudo systemctl status wp.service
Everything works fine - the containers run and stay running. Here is the output of sudo systemctl status wp.service
Aug 15 03:07:22 ip-172-31-33-87.ec2.internal docker-compose[4185]: ---> Using cache
Aug 15 03:07:22 ip-172-31-33-87.ec2.internal docker-compose[4185]: ---> 7392974149d3
Aug 15 03:07:22 ip-172-31-33-87.ec2.internal docker-compose[4185]: Successfully built 7392974149d3
Aug 15 03:07:22 ip-172-31-33-87.ec2.internal docker-compose[4185]: Successfully tagged foo_wp:latest
Aug 15 03:07:22 ip-172-31-33-87.ec2.internal docker-compose[4185]: Creating mysql ...
Aug 15 03:07:22 ip-172-31-33-87.ec2.internal docker-compose[4185]: [55B blob data]
Aug 15 03:07:23 ip-172-31-33-87.ec2.internal docker-compose[4185]: [37B blob data]
and the containers are up:
[ec2-user#ip-172-31-33-87 ~]$ sudo docker container ls -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
579b52c8e3bc foo_wp "docker-entrypoint.s…" About a minute ago Up About a minute 0.0.0.0:9101->80/tcp wp
3c418cfe2b9c mariadb:10.3.8-bionic "docker-entrypoint.s…" About a minute ago Up About a minute 3306/tcp mysql
If, however, I uncomment the ExecStop line above (and run docker-compos down and reload the service), then the containers are removed after they are run. The output of the status command is:
Loaded: loaded (/etc/systemd/system/wp.service; disabled; vendor preset: disabled)
Active: deactivating (stop) since Wed 2018-08-15 03:12:12 UTC; 7s ago
Process: 4862 ExecStart=/usr/bin/docker-compose up -d --build --remove-orphans (code=exited, status=0/SUCCESS)
Main PID: 4862 (code=exited, status=0/SUCCESS); : 5165 (docker-compose)
Tasks: 2
Memory: 19.0M
CGroup: /system.slice/wp.service
└─control
└─5165 /usr/bin/python2 /usr/bin/docker-compose down
Aug 15 03:12:11 ip-172-31-33-87.ec2.internal docker-compose[4862]: Step 3/3 : COPY wordpress/ /var/www/html/
Aug 15 03:12:11 ip-172-31-33-87.ec2.internal docker-compose[4862]: ---> Using cache
Aug 15 03:12:11 ip-172-31-33-87.ec2.internal docker-compose[4862]: ---> 7392974149d3
Aug 15 03:12:11 ip-172-31-33-87.ec2.internal docker-compose[4862]: Successfully built 7392974149d3
Aug 15 03:12:11 ip-172-31-33-87.ec2.internal docker-compose[4862]: Successfully tagged foo_wp:latest
Aug 15 03:12:11 ip-172-31-33-87.ec2.internal docker-compose[4862]: Creating mysql ...
Aug 15 03:12:11 ip-172-31-33-87.ec2.internal docker-compose[4862]: [55B blob data]
Aug 15 03:12:12 ip-172-31-33-87.ec2.internal docker-compose[4862]: [37B blob data]
Aug 15 03:12:12 ip-172-31-33-87.ec2.internal docker-compose[5165]: Stopping wp ...
Aug 15 03:12:12 ip-172-31-33-87.ec2.internal docker-compose[5165]: Stopping mysql ...
and the containers have been removed:
sudo docker container ls -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
[ec2-user#ip-172-31-33-87 foo]$
It seems as though the systemd service is executing the ExecStop script immediately after the ExecStart script. What could be the cause?
You are running docker-compose in detached mode (option -d). After starting the containers, docker-compose will daemonise the containers and exit.
Systemd monitors the PID of docker-compose, and when it exits, assumes that your program has stopped and will invoke the ExecStop commands.
Try running it without the -d option.
The reason systemd does this is because you haven't specified the type of your unit and by default it reverts to Type=simple.
See the official documentation for Type and ExecStop.

Postgres, Go Docker compose wait-for-it.sh no such file or directory

Been racking my head about this one for almost two days.
I'm new to Docker and Docker Compose, and trying to run my image on an EC2 instance running Postgres and Go. When I run docker-compose up, the db service runs successfully, but not the app service.
When I try to run the services separately using:
docker-compose up db all is good
then run:
docker-compose up app I get...
app_1 | wait-for-it.sh: waiting 15 seconds for db:5432
app_1 | wait-for-it.sh: db:5432 is available after 0 seconds
app_1 | ./wait-for-it.sh: line 174: /go/src/github.com/MY_USERNAME/MY_APP_DIR/EXECUTABLE: No such file or directory
some_name-golang_app_1 exited with code 127
Dockerfile-alternate:
FROM golang:latest
EXPOSE 8080
WORKDIR /go/src/github.com/MY_USERNAME/MY_APP_DIR
ADD . /go/src/github.com/MY_USERNAME/MY_APP_DIR
# Install all dependencies of the current project.
RUN go get -v
RUN go build
docker-compose.yml
version: '3'
services:
db:
image: postgres
environment:
POSTGRES_DB: dbname
POSTGRES_USER: miller
POSTGRES_PASSWORD: miller
ports:
- "6000:5432"
app:
build:
context: .
dockerfile: Dockerfile-alternate
command: ["./wait-for-it.sh", "db:5432", "--", "./EXECUTABLE"]
volumes:
- .:/go/src/github.com/gregpmillr/volume
ports:
- "80:8080"
depends_on:
- db
links:
- db
Interestingly enough, if I run docker run -it --rm MY_USERNAME/custom-go-image then I actually do see the EXECUTABLE file, and can run ./EXECUTABLE successfully... Well sort-of, I get a no such host error but pretty sure that's because I'm not starting them at the same time using docker-compose.
Any thought on this issue? Tips / resources would be great. I've been heading down rabbit holes of googling issues and leading nowhere. It's probably something small that I'm missing as per usual. Thanks!!
I'm looking to run postgres first (works correctly now), then run the go server which connects to postgres.
UPDATE 1
command: [ "sh", "-c", "cd /go/src/github.com/gregpmillr/volume && ls -l" ]
will give the following output:
db_1 | 2018-08-19 11:19:48.828 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
db_1 | 2018-08-19 11:19:48.828 UTC [1] LOG: listening on IPv6 address "::", port 5432
db_1 | 2018-08-19 11:19:48.831 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
db_1 | 2018-08-19 11:19:48.857 UTC [21] LOG: database system was shut down at 2018-08-19 01:03:35 UTC
db_1 | 2018-08-19 11:19:48.880 UTC [1] LOG: database system is ready to accept connections
app_1 | total 36
app_1 | -rw-rw-r-- 1 1000 1000 238 Aug 19 11:19 Dockerfile-alternate
app_1 | -rw-rw-r-- 1 1000 1000 260 Aug 17 19:24 Dockerrun.aws.json
app_1 | -rw-rw-r-- 1 1000 1000 62 Aug 17 18:56 README.md
app_1 | drwxrwxr-x 8 1000 1000 4096 Aug 17 19:00 app
app_1 | drwxrwxr-x 2 1000 1000 4096 Aug 17 19:34 config
app_1 | -rwxrwxr-x 1 1000 1000 708 Aug 17 19:48 deploy.sh
app_1 | -rw-rw-r-- 1 1000 1000 548 Aug 19 11:19 docker-compose.yml
app_1 | -rw-rw-r-- 1 1000 1000 1188 Aug 17 19:00 main.go
app_1 | -rwxrwxr-x 1 1000 1000 4079 Aug 17 19:00 wait-for-it.sh
app_1 exited with code 0
Dockerrun file is unnecessary as I'm not using elastic beanstalk atm.
UPDATE 2
Solved. See accepted answer. More specifically, see https://docs.docker.com/storage/ and https://docs.docker.com/storage/volumes/ for more info on Volumes. Thanks for the help!
You've added the go source code into your image and compiled it inside the image as part of your build. Then you overlaid that same path with a volume containing your source code (apparently without a compiled binary) by including the following:
volumes:
- .:/go/src/github.com/gregpmillr/Tranquility-Online-Golang
You either need the compiled binary in that volume, or skip mounting the volume into the container since it is blocking access to the files in your image.

Hyperledger cli container does not bind volumes with host

I am trying to implement the BYFN Hyperledger example form my Windows 10 Linux Subsystem (Ubuntu Xenial). However, the ./byfn.sh -m up command fails with the following output:
$GOPATH/fabric-samples/first-network$ ./byfn.sh -m up
Starting with channel 'mychannel' and CLI timeout of '10' seconds and CLI delay of '3' seconds
Continue? [Y/n] y
proceeding ...
2018-04-24 22:12:44.343 UTC [main] main -> INFO 001 Exiting.....
LOCAL_VERSION=1.1.0
DOCKER_IMAGE_VERSION=1.1.0
Creating peer0.org1.example.com ... done
Creating orderer.example.com ... done
Creating peer1.org1.example.com ... done
Creating peer0.org2.example.com ... done
Creating peer1.org2.example.com ... done
Creating cli ... done
OCI runtime exec failed: exec failed: container_linux.go:348: starting container process caused "exec: \"scripts/script.sh\": stat scripts/script.sh: no such file or directory": unknown
ERROR !!!! Test failed
I see that only one container is built:
$GOPATH/fabric-samples/first-network$ dps
CONTAINER ID NAMES NETWORKS STATUS SIZE
3e66d31c6b9a cli net_byfn Up 27 minutes 17B (virtual 1.46GB)
From the output it seems that the cli container cannot see the script.sh script. Thinking this maybe a docker-compose volume-bind issue I tried to check the binds in the cli container:
$GOPATH/fabric-samples/first-network$ docker exec -ti cli bash
root#3e66d31c6b9a:/opt/gopath/src/github.com/hyperledger/fabric/peer# ls scripts/
root#3e66d31c6b9a:/opt/gopath/src/github.com/hyperledger/fabric/peer# exit
exit
$GOPATH/fabric-samples/first-network$ ls scripts/
capabilities.json script.sh step1org3.sh step2org3.sh step3org3.sh testorg3.sh upgrade_to_v11.sh utils.sh
Looking at the the docker-compose-cli.yaml file I see the following binds for the cli container:
volumes:
- /var/run/:/host/var/run/
- ./../chaincode/:/opt/gopath/src/github.com/chaincode
- ./crypto-config:/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/
- ./scripts:/opt/gopath/src/github.com/hyperledger/fabric/peer/scripts/
- ./channel-artifacts:/opt/gopath/src/github.com/hyperledger/fabric/peer/channel-artifacts
My Docker settings:
$GOPATH/fabric-samples/first-network$ docker version
Client:
Version: 18.03.0-ce
API version: 1.37
Go version: go1.9.2
Git commit: 0520e24
Built: Wed Mar 21 23:05:52 2018
OS/Arch: linux/amd64
Experimental: false
Orchestrator: swarm
Server:
Engine:
Version: 18.03.0-ce
API version: 1.37 (minimum version 1.12)
Go version: go1.9.4
Git commit: 0520e24
Built: Wed Mar 21 23:14:32 2018
OS/Arch: linux/amd64
Experimental: false
$GOPATH/fabric-samples/first-network$ docker-compose version
docker-compose version 1.21.0, build 5920eb0
docker-py version: 3.2.1
CPython version: 3.6.5
OpenSSL version: OpenSSL 1.0.1t 3 May 2016
My Go version:
$GOPATH/fabric-samples/first-network$ go version
go version go1.10.1 linux/amd64
Wondering if I'm missing something. I should mention that I used the following command to start form scratch, based on a fresh set of images (no prior images) as outlined in this script:
curl -sSL https://raw.githubusercontent.com/hyperledger/fabric/master/scripts/bootstrap.sh | bash -s 1.1.0
Thanks
Its most probably the version of golang---Fabric needs go version 1.9.x and the error message exec failed: container_linux.go:348: indicates the same thing.
In my case, it was the first Note on this page https://hyperledger-fabric.readthedocs.io/en/latest/install.html
I'm running on Windows 10, but Docker won't work since i need Windows 10 Pro or better to run it. So i'm using Docker Toolbox, and must follow the Windows 7 trick of cloning the sources anywhere under C:\Users

Where are the Kubernetes kubelet logs located?

I installed Kubernetes on my Ubuntu machine. For some debugging purposes I need to look at the kubelet log file (if there is any such file).
I have looked in /var/logs but I couldn't find a such file. Where could that be?
If you run kubelet using systemd, then you could use the following method to see kubelet's logs:
# journalctl -u kubelet
If you are trying to go directly to the file you can find the kubelet logs in /var/log/syslog directory. This is for ubuntu 16.04 and above.
It depends how it was installed. I installed Kubernetes on some Ubuntu machines following the Docker-MultiNode instructions.
With this install, I find the logs using the logs command like this.
Find your container ID.
$ docker ps | egrep kubelet
Use that container ID to view the logs
$ docker logs `<container-id>`
Finally I could find it in /var/log/upstart directory. Kubernetes in my machine is started using upstart. That's why those log files are in upstart directory
I installed Kubernetes by kind (Kubernetes in docker).
find docker container of kind to enter
$ docker container ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
62588e4d284b kindest/node:v1.17.0 "/usr/local/bin/entr…" 2 weeks ago Up 2 weeks 127.0.0.1:32769->6443/tcp kind2-control-plane
$ docker container exec -it kind2-control-plane bash
root#kind2-control-plane:/#
Inside container kind2-control-plane, you could find logfiles in two place:
/var/log/containers/
/var/log/pods/
And then,you will find they are the same, you can see the example below:
root#kind2-control-plane:/# cat /var/log/containers/redis-master-7db7f6579f-scw95_default_master-f6374281c2c6afcfcd0ee1214d9bd51c1684c0b6c0ba1056295246ecd055563c.log | tail -n 5
2020-04-08T12:09:29.824252114Z stdout F
2020-04-08T12:09:29.824372278Z stdout F [1] 08 Apr 12:09:29.822 # Server started, Redis version 2.8.19
2020-04-08T12:09:29.824440661Z stdout F [1] 08 Apr 12:09:29.823 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
2020-04-08T12:09:29.824459317Z stdout F [1] 08 Apr 12:09:29.823 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
2020-04-08T12:09:29.82446451Z stdout F [1] 08 Apr 12:09:29.824 * The server is now ready to accept connections on port 6379
root#kind2-control-plane:/# cat /var/log/pods/default_redis-master-7db7f6579f-scw95_094824e1-25aa-4e1e-ab23-d4bae861988a/master/0.log | tail -n 5
2020-04-08T12:09:29.824252114Z stdout F
2020-04-08T12:09:29.824372278Z stdout F [1] 08 Apr 12:09:29.822 # Server started, Redis version 2.8.19
2020-04-08T12:09:29.824440661Z stdout F [1] 08 Apr 12:09:29.823 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
2020-04-08T12:09:29.824459317Z stdout F [1] 08 Apr 12:09:29.823 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
2020-04-08T12:09:29.82446451Z stdout F [1] 08 Apr 12:09:29.824 * The server is now ready to accept connections on port 6379
root#kind2-control-plane:/# ls -l /var/log/containers/ | grep redis
lrwxrwxrwx 1 root root 101 Apr 8 12:09 redis-master-7db7f6579f-scw95_default_master-f6374281c2c6afcfcd0ee1214d9bd51c1684c0b6c0ba1056295246ecd055563c.log -> /var/log/pods/default_redis-master-7db7f6579f-scw95_094824e1-25aa-4e1e-ab23-d4bae861988a/master/0.log
If you want to know more in detail about the directories, you can see 2019-2-merge-request in Github.