As per title: I've an issue with Loki (running on Docker) storing its chunks & C. on a bucket of AWS S3.
Loki is running fine, simply it stores its logs in the filesystem rather than in the bucket, and infact the bucket is empty.
What is wrong in my configuration?
In AWS, IAM, I've created a user with programmatic access, and I've give it the following policy ...
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "LokiStorage",
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::__myBucket__",
"arn:aws:s3:::__myBucket__/*"
]
}
]
}
The policy seems sufficient, since I've use it to push in the bucket some files present in the filesystem.
The relevant part of the docker compose...
version: "3.8"
volumes:
loki_data: {}
services:
loki:
image: grafana/loki:2.1.0
networks:
- my-overlay
ports:
- 3100:3100
volumes:
- ./loki/loki-config.yml:/etc/loki/local-config.yml
- loki_data:/loki
command: -config.file=/etc/loki/local-config.yaml
... Seems fine too: Loki - as container and service - runs smoothly.
The Loki's configuration file, "loki-config.yaml", seems also fine...
---
auth_enabled: false
ingester:
chunk_idle_period: 3m
chunk_block_size: 262144
chunk_retain_period: 1m
max_transfer_retries: 0
lifecycler:
ring:
kvstore:
store: inmemory
replication_factor: 1
limits_config:
enforce_metric_name: false
reject_old_samples: true
reject_old_samples_max_age: 168h
compactor:
working_directory: /loki/boltdb-shipper-compactor
shared_store: aws
schema_config:
configs:
- from: 2020-07-01
store: boltdb-shipper
object_store: aws
schema: v11
index:
prefix: loki_index_
period: 24h
server:
http_listen_port: 3100
storage_config:
aws:
s3: s3://__myAccessKey__:__mySecretAccessKey__#eu-west-1/__myBucket__
boltdb_shipper:
active_index_directory: /loki/index
shared_store: s3
cache_location: /loki/boltdb-cache
chunk_store_config:
max_look_back_period: 0s
table_manager:
retention_deletes_enabled: false
retention_period: 0s
... But, infact, there is something wrong and/or missing somewhere, somehow.
Suggestions?
I've found the culprit: there was an error in the docker-compose:
volumes:
- ./loki/loki-config.yml:/etc/loki/local-config.yml
### Here: "yml", and not "yaml" ──────────────────┘
- loki_data:/loki
command: -config.file=/etc/loki/local-config.yaml
### Here: "yaml", and not "yml" ─────────────┘
Now the compose is correct, and the Loki's configuration file is the following:
auth_enabled: false
server:
http_listen_port: 3100
ingester:
lifecycler:
address: 127.0.0.1
ring:
kvstore:
store: inmemory
replication_factor: 1
final_sleep: 0s
chunk_idle_period: 1h
max_chunk_age: 1h
chunk_target_size: 1048576
chunk_retain_period: 30s
max_transfer_retries: 0
schema_config:
configs:
- from: 2020-10-24
store: boltdb-shipper
object_store: s3
schema: v11
index:
prefix: index_
period: 24h
storage_config:
boltdb_shipper:
active_index_directory: /loki/index
cache_location: /loki/index_cache
cache_ttl: 24h # Can be increased for faster performance over longer query periods, uses more disk space
shared_store: s3
aws:
s3forcepathstyle: true
bucketnames: __myBucket__
region: eu-west-1
access_key_id: __myAccessKey__
secret_access_key: __mySecretAccessKey__
compactor:
working_directory: /loki/compactor
shared_store: s3
compaction_interval: 5m
limits_config:
reject_old_samples: true
reject_old_samples_max_age: 168h
ingestion_rate_mb: 16
ingestion_burst_size_mb: 32
chunk_store_config:
max_look_back_period: 0s
table_manager:
retention_deletes_enabled: false
retention_period: 0s
ruler:
storage:
type: s3
s3:
s3forcepathstyle: true
bucketnames: __myBucket__
region: eu-west-1
access_key_id: __myAccessKey__
secret_access_key: __mySecretAccessKey__
rule_path: /loki/rules-temp
alertmanager_url: http://localhost:9093
ring:
kvstore:
store: inmemory
enable_api: true
The configuration seems fine, since - at last! - the bucket of S3 is populated and Loki works fine.
Maybe.
Oddly enough: the bucket (as said) is populated, but I see that Loki also stores its chunks etc. in the local filesystem:
root#ip-aaa-bbb-ccc-ddd:/var/lib/docker/volumes/monit_loki_data# tree
.
└── _data
├── compactor
│ ├── index_19375
│ └── index_19376
├── index
│ └── uploader
│ └── name
├── index_cache
│ └── index_19376
│ ├── 5a22562e87b2-1674059149901907563-1674116100.gz
│ └── compactor-1674116450.gz
├── rules
└── tmprules
10 directories, 3 files
Hence the question: Loki really works as intended? That is: storing both in the bucket and in the filesystem it is its normal behaviour?
I have a dockerized flask app that I run with Gunicorn. Locally everything works fine by running the Gunicorn command in the docker-compose.yml. However, when I enter the same command in the AzureWebAppContainer#1 task's containerCommand field, it does not recognize the python flaskr module anymore.
The folder structure is as follows:
project/
├─ docker-compose.yml/
├─ azure-pipeline.yml/
├─ form/
│ ├─ flaskr
│ │ ├─ __init__.py
│ │ ├─ module1.py
│ │ ├─ module2.py
│ │ ├─ module2.py
│ ├─ templates
│ ├─ Dockerfile
│ ├─ requirements.txt
Where in the init.py I have the method:
def create_app(test_config=None):
\# create and configure the app
app = Flask(__name__, instance_relative_config=True)
return app
In my docker-compose.yml is as follows:
version: "3.7"
services:
project:
build:
context: ./project
dockerfile: Dockerfile
container_name: project
volumes:
\- ./project:/usr/src/app
env_file:
\- project/\_env.env
ports:
\- 5000:8080
command: gunicorn -b 0.0.0.0:8080 flaskr:create_app()
restart: always
Which works fine locally.
However, when I try to deploy the built container to an Azure Web App with the following pipeline:
- task: AzureWebAppContainer#1
displayName: 'Azure Web App on Container Deploy'
inputs:
azureSubscription: $(azureSubscription)
appName: $(appName)
imageName: $(pullRegistry)/$(imageRepository):$(Build.SourceVersion)
containerCommand: gunicorn -b 0.0.0.0:8080 flaskr:create_app()
I am getting the following error:
2022-09-09T15:25:42.727Z INFO - Pull Image successful, Time taken: 0 Minutes and 56 Seconds
2022-09-09T15:25:42.799Z INFO - Starting container for site
2022-09-09T15:25:42.800Z INFO - docker run -d --expose=80 --name wa-project-test_0_ac4d8bdf -e DOCKER_CUSTOM_IMAGE_NAME=project.azurecr.io/project:758 -e WEBSITES_ENABLE_APP_SERVICE_STORAGE=false -e WEBSITE_SITE_NAME=wa-project-test -e WEBSITE_AUTH_ENABLED=False -e PORT=80 -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_HOSTNAME=wa-project-test.azurewebsites.net -e WEBSITE_INSTANCE_ID=xxx-e WEBSITE_USE_DIAGNOSTIC_SERVER=False project.azurecr.io/project:xxxxx gunicorn -b 0.0.0.0:8080 flaskr:create_app()
2022-09-09T15:25:42.801Z INFO - Logging is not enabled for this container.
Please use https://aka.ms/linux-diagnostics to enable logging to see container logs here.
2022-09-09T15:25:48.801102626Z \[2022-09-09 15:25:48 +0000\] \[1\] \[INFO\] Starting gunicorn 20.1.0
2022-09-09T15:25:48.805756581Z \[2022-09-09 15:25:48 +0000\] \[1\] \[INFO\] Listening at: http://0.0.0.0:8080 (1)
2022-09-09T15:25:48.805795943Z \[2022-09-09 15:25:48 +0000\] \[1\] \[INFO\] Using worker: sync
2022-09-09T15:25:48.824303764Z \[2022-09-09 15:25:48 +0000\] \[7\] \[INFO\] Booting worker with pid: 7
2022-09-09T15:25:48.830298138Z \[2022-09-09 15:25:48 +0000\] \[7\] \[ERROR\] Exception in worker process
2022-09-09T15:25:48.830335202Z Traceback (most recent call last):
2022-09-09T15:25:48.830344993Z File "/usr/local/lib/python3.8/site-packages/gunicorn/arbiter.py", line 589, in spawn_worker
2022-09-09T15:25:48.830352886Z worker.init_process()
2022-09-09T15:25:48.830359979Z File "/usr/local/lib/python3.8/site-packages/gunicorn/workers/base.py", line 134, in init_process
2022-09-09T15:25:48.830367172Z self.load_wsgi()
2022-09-09T15:25:48.830373266Z File "/usr/local/lib/python3.8/site-packages/gunicorn/workers/base.py", line 146, in load_wsgi
2022-09-09T15:25:48.830380060Z self.wsgi = self.app.wsgi()
2022-09-09T15:25:48.830386653Z File "/usr/local/lib/python3.8/site-packages/gunicorn/app/base.py", line 67, in wsgi
2022-09-09T15:25:48.830394346Z self.callable = self.load()
2022-09-09T15:25:48.830401539Z File "/usr/local/lib/python3.8/site-packages/gunicorn/app/wsgiapp.py", line 58, in load
2022-09-09T15:25:48.830408333Z return self.load_wsgiapp()
2022-09-09T15:25:48.830414527Z File "/usr/local/lib/python3.8/site-packages/gunicorn/app/wsgiapp.py", line 48, in load_wsgiapp
2022-09-09T15:25:48.830421420Z return util.import_app(self.app_uri)
2022-09-09T15:25:48.830428413Z File "/usr/local/lib/python3.8/site-packages/gunicorn/util.py", line 359, in import_app
2022-09-09T15:25:48.830475668Z mod = importlib.import_module(module)
2022-09-09T15:25:48.830485159Z File "/usr/local/lib/python3.8/importlib/__init__.py", line 127, in import_module
2022-09-09T15:25:48.830492053Z return \_bootstrap.\_gcd_import(name\[level:\], package, level)
2022-09-09T15:25:48.830498247Z File "\<frozen importlib.\_bootstrap\>", line 1014, in \_gcd_import
2022-09-09T15:25:48.830505440Z File "\<frozen importlib.\_bootstrap\>", line 991, in \_find_and_load
2022-09-09T15:25:48.830512433Z File "\<frozen importlib.\_bootstrap\>", line 973, in \_find_and_load_unlocked
2022-09-09T15:25:48.830520426Z ModuleNotFoundError: No module named 'flaskr'
2022-09-09T15:25:48.830526620Z \[2022-09-09 15:25:48 +0000\] \[7\] \[INFO\] Worker exiting (pid: 7)
2022-09-09T15:25:48.883451664Z \[2022-09-09 15:25:48 +0000\] \[1\] \[INFO\] Shutting down: Master
2022-09-09T15:25:48.884026615Z \[2022-09-09 15:25:48 +0000\] \[1\] \[INFO\] Reason: Worker failed to boot.
2022-09-09T15:25:48.709Z INFO - Initiating warmup request to container wa-project-test_0_ac4d8bdf for site wa-project-test
2022-09-09T15:25:49.756Z ERROR - Container wa-project-test_0_ac4d8bdf for site wa-project-test has exited, failing site start
2022-09-09T15:25:49.836Z ERROR - Container wa-project-test_0_ac4d8bdf didn't respond to HTTP pings on port: 80, failing site start. See container logs for debugging.
2022-09-09T15:25:49.889Z INFO - Stopping site wa-project-test because it failed during startup.
I get this error more often with Gunicorn when I try to run directly in the Dockerfile instead of through docker-compose. Has anyone encountered this before or knows a solution?
I have a 1.16.2 version cluster of kubernetes. When I deploy all the service in the cluster with the replicas is 1, it works fine. Then i scale all the service's replicas to 2 And check out. found that some service are running Normal but But some states are pending.
when I kubectl describe one of the Pending pod, I get the message like below
[root#runsdata-bj-01 society-training-service-v1-0]# kcd society-resident-service-v3-0-788446c49b-rzjsx
Name: society-resident-service-v3-0-788446c49b-rzjsx
Namespace: runsdata
Priority: 0
Node: <none>
Labels: app=society-resident-service-v3-0
pod-template-hash=788446c49b
Annotations: <none>
Status: Pending
IP:
IPs: <none>
Controlled By: ReplicaSet/society-resident-service-v3-0-788446c49b
Containers:
society-resident-service-v3-0:
Image: docker.ssiid.com/society-resident-service:3.0.33
Port: 8231/TCP
Host Port: 0/TCP
Limits:
cpu: 1
memory: 4Gi
Requests:
cpu: 200m
memory: 2Gi
Liveness: http-get http://:8231/actuator/health delay=600s timeout=5s period=10s #success=1 #failure=3
Readiness: http-get http://:8231/actuator/health delay=30s timeout=5s period=10s #success=1 #failure=3
Environment:
spring_profiles_active: production
TZ: Asia/Hong_Kong
JAVA_OPTS: -Djgroups.use.jdk_logger=true -Xmx4000M -Xms4000M -Xmn600M -XX:PermSize=500M -XX:MaxPermSize=500M -Xss384K -XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:LargePageSizeInBytes=128M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log
Mounts:
/data/storage from nfs-data-storage (rw)
/opt/security from security (rw)
/var/log/runsdata from log (rw)
/var/run/secrets/kubernetes.io/serviceaccount from application-token-vgcvb (ro)
Conditions:
Type Status
PodScheduled False
Volumes:
log:
Type: HostPath (bare host directory volume)
Path: /log/runsdata
HostPathType:
security:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: data-security-claim
ReadOnly: false
nfs-data-storage:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: data-storage-claim
ReadOnly: false
application-token-vgcvb:
Type: Secret (a volume populated by a Secret)
SecretName: application-token-vgcvb
Optional: false
QoS Class: Burstable
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling <unknown> default-scheduler 0/4 nodes are available: 4 Insufficient memory.
And from below, you can see that my machine have more than 2G memory left .
[root#runsdata-bj-01 society-training-service-v1-0]# kcp |grep Pending
society-insurance-foundation-service-v2-0-7697b9bd5b-7btq6 0/1 Pending 0 60m
society-notice-service-v1-0-548b8d5946-c5gzm 0/1 Pending 0 60m
society-online-business-service-v2-1-7f897f564-phqjs 0/1 Pending 0 60m
society-operation-gateway-7cf86b77bd-lmswm 0/1 Pending 0 60m
society-operation-user-service-v1-1-755dcff964-dr9mj 0/1 Pending 0 60m
society-resident-service-v3-0-788446c49b-rzjsx 0/1 Pending 0 60m
society-training-service-v1-0-774f8c5d98-tl7vq 0/1 Pending 0 60m
society-user-service-v3-0-74865dd9d7-t9fwz 0/1 Pending 0 60m
traefik-ingress-controller-8688cccf79-5gkjg 0/1 Pending 0 60m
[root#runsdata-bj-01 society-training-service-v1-0]# kubectl top nodes
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
192.168.0.94 384m 9% 11482Mi 73%
192.168.0.95 399m 9% 11833Mi 76%
192.168.0.96 399m 9% 11023Mi 71%
192.168.0.97 457m 11% 10782Mi 69%
[root#runsdata-bj-01 society-training-service-v1-0]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
192.168.0.94 Ready <none> 8d v1.16.2
192.168.0.95 Ready <none> 8d v1.16.2
192.168.0.96 Ready <none> 8d v1.16.2
192.168.0.97 Ready <none> 8d v1.16.2
[root#runsdata-bj-01 society-training-service-v1-0]#
here is the description of all 4 node
[root#runsdata-bj-01 frontend]#kubectl describe node 192.168.0.94
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 1930m (48%) 7600m (190%)
memory 9846Mi (63%) 32901376Ki (207%)
ephemeral-storage 0 (0%) 0 (0%)
Events: <none>
[root#runsdata-bj-01 frontend]#kubectl describe node 192.168.0.95
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 1670m (41%) 6600m (165%)
memory 7196Mi (46%) 21380Mi (137%)
ephemeral-storage 0 (0%) 0 (0%)
Events: <none>
[root#runsdata-bj-01 frontend]# kubectl describe node 192.168.0.96
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 2610m (65%) 7 (175%)
memory 9612Mi (61%) 19960Mi (128%)
ephemeral-storage 0 (0%) 0 (0%)
Events: <none>
[root#runsdata-bj-01 frontend]# kubectl describe node 192.168.0.97
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 2250m (56%) 508200m (12705%)
memory 10940Mi (70%) 28092672Ki (176%)
ephemeral-storage 0 (0%) 0 (0%)
Events: <none>
And the memory of all the 4 node:
[root#runsdata-bj-00 ~]# free -h
total used free shared buff/cache available
Mem: 15G 2.8G 6.7G 2.1M 5.7G 11G
Swap: 0B 0B 0B
[root#runsdata-bj-01 frontend]# free -h
total used free shared buff/cache available
Mem: 15G 7.9G 3.7G 2.4M 3.6G 6.8G
Swap: 0B 0B 0B
[root#runsdata-bj-02 ~]# free -h
total used free shared buff/cache available
Mem: 15G 5.0G 2.9G 3.9M 7.4G 9.5G
Swap: 0B 0B 0B
[root#runsdata-bj-03 ~]# free -h
total used free shared buff/cache available
Mem: 15G 6.5G 2.2G 2.3M 6.6G 8.2G
Swap: 0B 0B 0B
here is the kube-scheduler log:
[root#runsdata-bj-01 log]# cat messages|tail -n 5000|grep kube-scheduler
Apr 17 14:31:24 runsdata-bj-01 kube-scheduler: E0417 14:31:24.404442 12740 factory.go:585] pod is already present in the activeQ
Apr 17 14:31:25 runsdata-bj-01 kube-scheduler: E0417 14:31:25.490310 12740 factory.go:585] pod is already present in the backoffQ
Apr 17 14:31:25 runsdata-bj-01 kube-scheduler: E0417 14:31:25.873292 12740 factory.go:585] pod is already present in the backoffQ
Apr 18 21:44:18 runsdata-bj-01 etcd: read-only range request "key:\"/registry/services/endpoints/kube-system/kube-scheduler\" " with result "range_response_count:1 size:440" took too long (100.521269ms) to execute
Apr 18 21:59:40 runsdata-bj-01 kube-scheduler: E0418 21:59:40.050852 12740 factory.go:585] pod is already present in the activeQ
Apr 18 22:03:07 runsdata-bj-01 kube-scheduler: E0418 22:03:07.069465 12740 factory.go:585] pod is already present in the activeQ
Apr 18 22:03:07 runsdata-bj-01 kube-scheduler: E0418 22:03:07.950254 12740 factory.go:585] pod is already present in the activeQ
Apr 18 22:03:08 runsdata-bj-01 kube-scheduler: E0418 22:03:08.567290 12740 factory.go:585] pod is already present in the activeQ
Apr 18 22:03:09 runsdata-bj-01 kube-scheduler: E0418 22:03:09.152812 12740 factory.go:585] pod is already present in the activeQ
Apr 18 22:03:09 runsdata-bj-01 kube-scheduler: E0418 22:03:09.344902 12740 factory.go:585] pod is already present in the activeQ
Apr 18 22:04:32 runsdata-bj-01 kube-scheduler: E0418 22:04:32.969606 12740 factory.go:585] pod is already present in the activeQ
Apr 18 22:09:51 runsdata-bj-01 kube-scheduler: E0418 22:09:51.366877 12740 factory.go:585] pod is already present in the activeQ
Apr 18 22:32:16 runsdata-bj-01 kube-scheduler: E0418 22:32:16.430976 12740 factory.go:585] pod is already present in the activeQ
Apr 18 22:32:16 runsdata-bj-01 kube-scheduler: E0418 22:32:16.441182 12740 factory.go:585] pod is already present in the activeQ
I searched google and stackoverflow and can not found the solution.
who can help me ?
Kubernetes preserves the node stability instead the resource provisioning, the memory available is not calculate based on free -m command, as the documentation mention:
The value for memory.available is derived from the cgroupfs instead of tools like free -m. This is important because free -m does not work in a container, and if users use the node allocatable feature, out of resource decisions are made local to the end user Pod part of the cgroup hierarchy as well as the root node. This script reproduces the same set of steps that the kubelet performs to calculate memory.available. The kubelet excludes inactive_file (i.e. # of bytes of file-backed memory on inactive LRU list) from its calculation as it assumes that memory is reclaimable under pressure.
You could use the script mentioned above to check your memory available in the nodes and if there's no available resource you will need to increase the cluster size adding a new node.
Additionally, you can check the documenation page for more information about resources limits
SUMMARY:
When I run the following command...
docker-compose up --build --exit-code-from combined --timeout 600; echo $?
My init.sh script, which is the entrypoint for my combined container, is run twice instead of once. I expect the init.sh script to be run only once. Why is this happening and how can I make it run only once?
THE FULL STORY:
I have two Docker containers:
b-db - contains my database
b-combined - contains my web application and a series of tests, which run once the container is up and running.
I'm using a docker-compose.yml file to start both containers.
version: '3'
services:
db:
build:
context: .
dockerfile: ./docker/db/Dockerfile
container_name: b-db
restart: unless-stopped
volumes:
- dbdata:/data/db
ports:
- "27017:27017"
networks:
- app-network
combined:
build:
context: .
dockerfile: ./docker/combined/Dockerfile
container_name: b-combined
restart: unless-stopped
env_file: .env
ports:
- "5000:5000"
- "8080:8080"
networks:
- app-network
depends_on:
- db
networks:
app-network:
driver: bridge
volumes:
dbdata:
node_modules:
Below is the Dockerfile for the combined service in docker-compose.yml.
FROM cypress/included:3.4.1
WORKDIR /usr/src/app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 5000
RUN npm install -g history-server nodemon
RUN npm run build-test
EXPOSE 8080
COPY ./docker/combined/init.sh /scripts/init.sh
RUN ["chmod", "+x", "/scripts/init.sh"]
ENTRYPOINT [ "/scripts/init.sh" ]
Below is what is in my init.sh file.
#!/bin/bash
# Start front end server
history-server dist -p 8080 &
front_pid=$!
# Start back end server that interacts with DB
nodemon -L server &
back_pid=$!
# Run a specific test
NODE_ENV=test $(npm bin)/cypress run --spec "cypress/integration/analytics_spec.js"
# Error code of the test
test_exit_code=$?
echo "TEST ENDED WITH EXIT CODE OF: $test_exit_code"
# End front and backend server
kill -9 $front_pid
kill -9 $back_pid
# Exit with the error code of the test
echo "EXITING SCRIPT WITH EXIT CODE OF: $test_exit_code"
exit "$test_exit_code"
Below is the Dockerfile for my db service. All its doing is copying some local data into the Docker container and then initialising the database with this data.
FROM mongo:3.6.14-xenial
COPY ./dump/ /tmp/dump/
COPY mongo_restore.sh /docker-entrypoint-initdb.d/
RUN chmod 777 /docker-entrypoint-initdb.d/mongo_restore.sh
Below is what is in mongo_restore.sh.
#!/bin/bash
# Creates db using copied data
mongorestore /tmp/dump
When I run the following command...
docker-compose up --build --exit-code-from combined --timeout 600; echo $?
I get the following output:
Building db
Step 1/4 : FROM mongo:3.6.14-xenial
---> 63abac6699cd
Step 2/4 : COPY ./dump/ /tmp/dump/
---> Using cache
---> c63b5bb8a6e6
Step 3/4 : COPY mongo_restore.sh /docker-entrypoint-initdb.d/
---> Using cache
---> 62de88a27f64
Step 4/4 : RUN chmod 777 /docker-entrypoint-initdb.d/mongo_restore.sh
---> Using cache
---> 041757bccef5
Successfully built 041757bccef5
Successfully tagged b-property_db:latest
Building combined
Step 1/17 : FROM cypress/included:3.4.1
---> 27da0246551c
Step 2/17 : WORKDIR /usr/src/app
---> Using cache
---> eea587fa33f8
Step 3/17 : RUN npm install -g n
---> Using cache
---> 6ee678f738a0
Step 4/17 : RUN n 9.2.0
---> Using cache
---> 27406ead3cff
Step 5/17 : COPY package*.json ./
---> Using cache
---> 7793be158259
Step 6/17 : RUN npm install npm#6.9.0
---> Using cache
---> ec6e4bae63ac
Step 7/17 : RUN rm -rf /usr/local/lib/node_modules/npm
---> Using cache
---> 3cbf0c0c0ec2
Step 8/17 : RUN mv node_modules/npm /usr/local/lib/node_modules/npm
---> Using cache
---> f92096e43ae1
Step 9/17 : RUN npm install
---> Using cache
---> c4b556ca3240
Step 10/17 : COPY . .
---> Using cache
---> 2c63f18d836d
Step 11/17 : EXPOSE 5000
---> Using cache
---> 8b8e1e7bab2b
Step 12/17 : RUN npm install -g history-server nodemon
---> Using cache
---> da8e46eb02b1
Step 13/17 : RUN npm run build-test
---> Using cache
---> 424f7171c913
Step 14/17 : EXPOSE 8080
---> Using cache
---> ef25e1f0d272
Step 15/17 : COPY ./docker/combined/init.sh /scripts/init.sh
---> Using cache
---> bd14264aac05
Step 16/17 : RUN ["chmod", "+x", "/scripts/init.sh"]
---> Using cache
---> 214afacc9ace
Step 17/17 : ENTRYPOINT [ "/scripts/init.sh" ]
---> Using cache
---> 9ed5241c92f1
Successfully built 9ed5241c92f1
Successfully tagged b-property_combined:latest
Recreating b-db ... done
Recreating b-combined ... done
Attaching to b-db, b-combined
b-db | 2019-12-13T11:27:30.229+0000 I CONTROL [initandlisten] MongoDB starting : pid=1 port=27017 dbpath=/data/db 64-bit host=3bbb8f5fe956
b-db | 2019-12-13T11:27:30.229+0000 I CONTROL [initandlisten] db version v3.6.14
b-db | 2019-12-13T11:27:30.229+0000 I CONTROL [initandlisten] git version: cbef87692475857c7ee6e764c8f5104b39c342a1
b-db | 2019-12-13T11:27:30.229+0000 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.2g 1 Mar 2016
b-db | 2019-12-13T11:27:30.229+0000 I CONTROL [initandlisten] allocator: tcmalloc
b-db | 2019-12-13T11:27:30.229+0000 I CONTROL [initandlisten] modules: none
b-db | 2019-12-13T11:27:30.229+0000 I CONTROL [initandlisten] build environment:
b-db | 2019-12-13T11:27:30.229+0000 I CONTROL [initandlisten] distmod: ubuntu1604
b-db | 2019-12-13T11:27:30.229+0000 I CONTROL [initandlisten] distarch: x86_64
b-db | 2019-12-13T11:27:30.229+0000 I CONTROL [initandlisten] target_arch: x86_64
b-db | 2019-12-13T11:27:30.229+0000 I CONTROL [initandlisten] options: { net: { bindIpAll: true } }
b-db | 2019-12-13T11:27:30.230+0000 I - [initandlisten] Detected data files in /data/db created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
b-db | 2019-12-13T11:27:30.230+0000 I STORAGE [initandlisten]
b-db | 2019-12-13T11:27:30.230+0000 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
b-db | 2019-12-13T11:27:30.230+0000 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
b-db | 2019-12-13T11:27:30.230+0000 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=2466M,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),compatibility=(release="3.0",require_max="3.0"),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),
b-db | 2019-12-13T11:27:30.882+0000 I STORAGE [initandlisten] WiredTiger message [1576236450:882897][1:0x7f78cf0bca40], txn-recover: Main recovery loop: starting at 70/242560
b-db | 2019-12-13T11:27:30.960+0000 I STORAGE [initandlisten] WiredTiger message [1576236450:960786][1:0x7f78cf0bca40], txn-recover: Recovering log 70 through 71
b-db | 2019-12-13T11:27:31.025+0000 I STORAGE [initandlisten] WiredTiger message [1576236451:25011][1:0x7f78cf0bca40], txn-recover: Recovering log 71 through 71
b-db | 2019-12-13T11:27:31.073+0000 I STORAGE [initandlisten] WiredTiger message [1576236451:73785][1:0x7f78cf0bca40], txn-recover: Set global recovery timestamp: 0
b-db | 2019-12-13T11:27:31.111+0000 I CONTROL [initandlisten]
b-db | 2019-12-13T11:27:31.111+0000 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
b-db | 2019-12-13T11:27:31.111+0000 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
b-db | 2019-12-13T11:27:31.111+0000 I CONTROL [initandlisten]
b-db | 2019-12-13T11:27:31.113+0000 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory '/data/db/diagnostic.data'
b-db | 2019-12-13T11:27:31.114+0000 I NETWORK [initandlisten] waiting for connections on port 27017
b-combined | [nodemon] 2.0.2
b-combined | [nodemon] to restart at any time, enter `rs`
b-combined | [nodemon] watching dir(s): *.*
b-combined | [nodemon] watching extensions: js,mjs,json
b-combined | [nodemon] starting `node server.js`
b-combined | history-server listening on port 8080; Ctrl+C to stop
b-combined | raven#2.6.4 alert: no DSN provided, error reporting disabled
b-combined | test
b-combined | server started 5000
b-db | 2019-12-13T11:27:32.336+0000 I NETWORK [listener] connection accepted from 172.22.0.3:33086 #1 (1 connection now open)
b-db | 2019-12-13T11:27:32.340+0000 I NETWORK [conn1] received client metadata from 172.22.0.3:33086 conn1: { driver: { name: "nodejs", version: "3.2.7" }, os: { type: "Linux", name: "linux", architecture: "x64", version: "4.9.125-linuxkit" }, platform: "Node.js v9.2.0, LE, mongodb-core: 3.2.7" }
b-combined | Mongoose connected to mongodb://db:27017/book-test
b-db | 2019-12-13T11:27:32.359+0000 I NETWORK [listener] connection accepted from 172.22.0.3:33088 #2 (2 connections now open)
b-db | 2019-12-13T11:27:32.361+0000 I NETWORK [conn2] received client metadata from 172.22.0.3:33088 conn2: { driver: { name: "nodejs", version: "3.2.7" }, os: { type: "Linux", name: "linux", architecture: "x64", version: "4.9.125-linuxkit" }, platform: "Node.js v9.2.0, LE, mongodb-core: 3.2.7" }
b-db | 2019-12-13T11:27:32.364+0000 I NETWORK [listener] connection accepted from 172.22.0.3:33090 #3 (3 connections now open)
b-db | 2019-12-13T11:27:32.366+0000 I NETWORK [conn3] received client metadata from 172.22.0.3:33090 conn3: { driver: { name: "nodejs", version: "3.2.7" }, os: { type: "Linux", name: "linux", architecture: "x64", version: "4.9.125-linuxkit" }, platform: "Node.js v9.2.0, LE, mongodb-core: 3.2.7" }
b-db | 2019-12-13T11:27:36.866+0000 I NETWORK [listener] connection accepted from 172.22.0.3:33092 #4 (4 connections now open)
b-db | 2019-12-13T11:27:36.874+0000 I NETWORK [conn4] received client metadata from 172.22.0.3:33092 conn4: { driver: { name: "nodejs", version: "3.2.7" }, os: { type: "Linux", name: "linux", architecture: "x64", version: "4.9.125-linuxkit" }, platform: "Node.js v8.9.3, LE, mongodb-core: 3.2.7" }
b-db | 2019-12-13T11:27:36.874+0000 I NETWORK [listener] connection accepted from 172.22.0.3:33094 #5 (5 connections now open)
b-combined | Mongoose connected to mongodb://db:27017/book-test
b-db | 2019-12-13T11:27:36.892+0000 I NETWORK [conn5] received client metadata from 172.22.0.3:33094 conn5: { driver: { name: "nodejs", version: "3.2.7" }, os: { type: "Linux", name: "linux", architecture: "x64", version: "4.9.125-linuxkit" }, platform: "Node.js v8.9.3, LE, mongodb-core: 3.2.7" }
b-db | 2019-12-13T11:27:36.896+0000 I NETWORK [listener] connection accepted from 172.22.0.3:33096 #6 (6 connections now open)
b-db | 2019-12-13T11:27:36.897+0000 I NETWORK [conn6] received client metadata from 172.22.0.3:33096 conn6: { driver: { name: "nodejs", version: "3.2.7" }, os: { type: "Linux", name: "linux", architecture: "x64", version: "4.9.125-linuxkit" }, platform: "Node.js v8.9.3, LE, mongodb-core: 3.2.7" }
b-db | 2019-12-13T11:27:36.902+0000 I NETWORK [listener] connection accepted from 172.22.0.3:33098 #7 (7 connections now open)
b-db | 2019-12-13T11:27:36.903+0000 I NETWORK [conn7] received client metadata from 172.22.0.3:33098 conn7: { driver: { name: "nodejs", version: "3.2.7" }, os: { type: "Linux", name: "linux", architecture: "x64", version: "4.9.125-linuxkit" }, platform: "Node.js v8.9.3, LE, mongodb-core: 3.2.7" }
b-combined |
b-combined | ====================================================================================================
b-combined |
b-combined | (Run Starting)
b-combined |
b-combined | ┌────────────────────────────────────────────────────────────────────────────────────────────────┐
b-combined | │ Cypress: 3.4.1 │
b-combined | │ Browser: Chrome 75 │
b-combined | │ Specs: 1 found (analytics_spec.js) │
b-combined | │ Searched: cypress/integration/analytics_spec.js │
b-combined | └────────────────────────────────────────────────────────────────────────────────────────────────┘
b-combined |
b-combined |
b-combined | ────────────────────────────────────────────────────────────────────────────────────────────────────
b-combined |
b-combined | Running: analytics_spec.js... (1 of 1)
b-combined |
b-combined |
b-combined | Analytics
b-combined | (node:212) DeprecationWarning: collection.remove is deprecated. Use deleteOne, deleteMany, or bulkWrite instead.
b-combined | (node:212) DeprecationWarning: collection.update is deprecated. Use updateOne, updateMany, or bulkWrite instead.
✓ displays listings on the side bar lazily for upcoming events (6113ms)
b-combined | user disconnected
b-combined | user disconnected
✓ displays listings on the side bar lazily for archived events (3635ms)
b-combined | user disconnected
b-combined | user disconnected
✓ allows the user to click between upcoming and archived (3538ms)
b-combined | user disconnected
b-combined | user disconnected
b-combined | user disconnected
b-combined | (node:30) DeprecationWarning: Mongoose: `findOneAndUpdate()` and `findOneAndDelete()` without the `useFindAndModify` option set to false are deprecated. See: https://mongoosejs.com/docs/deprecations.html#-findandmodify-
✓ updates prediction and view count (8660ms)
b-combined | user disconnected
b-combined | user disconnected
b-combined | user disconnected
b-combined | user disconnected
✓ takes users to the correct routes (7302ms)
b-combined |
b-combined |
b-combined | 5 passing (30s)
b-combined |
b-combined |
b-combined | (Results)
b-combined |
b-combined | ┌─────────────────────────────────┐
b-combined | │ Tests: 5 │
b-combined | │ Passing: 5 │
b-combined | │ Failing: 0 │
b-combined | │ Pending: 0 │
b-combined | │ Skipped: 0 │
b-combined | │ Screenshots: 0 │
b-combined | │ Video: false │
b-combined | │ Duration: 29 seconds │
b-combined | │ Spec Ran: analytics_spec.js │
b-combined | └─────────────────────────────────┘
b-combined |
b-combined |
b-combined | ====================================================================================================
b-combined |
b-combined | (Run Finished)
b-combined |
b-combined |
b-combined | Spec Tests Passing Failing Pending Skipped
b-combined | ┌────────────────────────────────────────────────────────────────────────────────────────────────┐
b-combined | │ ✔ analytics_spec.js 00:29 5 5 - - - │
b-combined | └────────────────────────────────────────────────────────────────────────────────────────────────┘
b-combined | All specs passed! 00:29 5 5 - - -
b-combined |
b-combined | Mongoose disconnected
b-db | 2019-12-13T11:28:09.278+0000 I NETWORK [conn4] end connection 172.22.0.3:33092 (6 connections now open)
b-db | 2019-12-13T11:28:09.279+0000 I NETWORK [conn6] end connection 172.22.0.3:33096 (5 connections now open)
b-combined | Mongoose disconnected through app shutdown
b-db | 2019-12-13T11:28:09.279+0000 I NETWORK [conn7] end connection 172.22.0.3:33098 (4 connections now open)
b-db | 2019-12-13T11:28:09.305+0000 I NETWORK [conn5] end connection 172.22.0.3:33094 (3 connections now open)
b-combined | user disconnected
b-combined | TEST ENDED WITH EXIT CODE OF: 0 ===========================
b-combined | EXITING SCRIPT WITH EXIT CODE OF: 0 =====================================
b-db | 2019-12-13T11:28:09.512+0000 I NETWORK [conn2] end connection 172.22.0.3:33088 (2 connections now open)
b-db | 2019-12-13T11:28:09.512+0000 I NETWORK [conn3] end connection 172.22.0.3:33090 (1 connection now open)
b-db | 2019-12-13T11:28:09.512+0000 I NETWORK [conn1] end connection 172.22.0.3:33086 (0 connections now open)
b-combined | [nodemon] 2.0.2
b-combined | [nodemon] to restart at any time, enter `rs`
b-combined | [nodemon] watching dir(s): *.*
b-combined | [nodemon] watching extensions: js,mjs,json
b-combined | [nodemon] starting `node server.js`
b-combined | history-server listening on port 8080; Ctrl+C to stop
b-combined | raven#2.6.4 alert: no DSN provided, error reporting disabled
b-combined | test
b-combined | server started 5000
b-db | 2019-12-13T11:28:13.290+0000 I NETWORK [listener] connection accepted from 172.22.0.3:33342 #8 (1 connection now open)
b-db | 2019-12-13T11:28:13.293+0000 I NETWORK [conn8] received client metadata from 172.22.0.3:33342 conn8: { driver: { name: "nodejs", version: "3.2.7" }, os: { type: "Linux", name: "linux", architecture: "x64", version: "4.9.125-linuxkit" }, platform: "Node.js v9.2.0, LE, mongodb-core: 3.2.7" }
b-combined | Mongoose connected to mongodb://db:27017/book-test
b-db | 2019-12-13T11:28:13.312+0000 I NETWORK [listener] connection accepted from 172.22.0.3:33344 #9 (2 connections now open)
b-db | 2019-12-13T11:28:13.313+0000 I NETWORK [conn9] received client metadata from 172.22.0.3:33344 conn9: { driver: { name: "nodejs", version: "3.2.7" }, os: { type: "Linux", name: "linux", architecture: "x64", version: "4.9.125-linuxkit" }, platform: "Node.js v9.2.0, LE, mongodb-core: 3.2.7" }
b-db | 2019-12-13T11:28:13.317+0000 I NETWORK [listener] connection accepted from 172.22.0.3:33346 #10 (3 connections now open)
b-db | 2019-12-13T11:28:13.317+0000 I NETWORK [conn10] received client metadata from 172.22.0.3:33346 conn10: { driver: { name: "nodejs", version: "3.2.7" }, os: { type: "Linux", name: "linux", architecture: "x64", version: "4.9.125-linuxkit" }, platform: "Node.js v9.2.0, LE, mongodb-core: 3.2.7" }
b-db | 2019-12-13T11:28:17.821+0000 I NETWORK [listener] connection accepted from 172.22.0.3:33348 #11 (4 connections now open)
b-db | 2019-12-13T11:28:17.826+0000 I NETWORK [conn11] received client metadata from 172.22.0.3:33348 conn11: { driver: { name: "nodejs", version: "3.2.7" }, os: { type: "Linux", name: "linux", architecture: "x64", version: "4.9.125-linuxkit" }, platform: "Node.js v8.9.3, LE, mongodb-core: 3.2.7" }
b-combined | Mongoose connected to mongodb://db:27017/book-test
b-db | 2019-12-13T11:28:17.843+0000 I NETWORK [listener] connection accepted from 172.22.0.3:33350 #12 (5 connections now open)
b-db | 2019-12-13T11:28:17.849+0000 I NETWORK [conn12] received client metadata from 172.22.0.3:33350 conn12: { driver: { name: "nodejs", version: "3.2.7" }, os: { type: "Linux", name: "linux", architecture: "x64", version: "4.9.125-linuxkit" }, platform: "Node.js v8.9.3, LE, mongodb-core: 3.2.7" }
b-db | 2019-12-13T11:28:17.851+0000 I NETWORK [listener] connection accepted from 172.22.0.3:33352 #13 (6 connections now open)
b-db | 2019-12-13T11:28:17.851+0000 I NETWORK [conn13] received client metadata from 172.22.0.3:33352 conn13: { driver: { name: "nodejs", version: "3.2.7" }, os: { type: "Linux", name: "linux", architecture: "x64", version: "4.9.125-linuxkit" }, platform: "Node.js v8.9.3, LE, mongodb-core: 3.2.7" }
b-db | 2019-12-13T11:28:17.857+0000 I NETWORK [listener] connection accepted from 172.22.0.3:33354 #14 (7 connections now open)
b-db | 2019-12-13T11:28:17.857+0000 I NETWORK [conn14] received client metadata from 172.22.0.3:33354 conn14: { driver: { name: "nodejs", version: "3.2.7" }, os: { type: "Linux", name: "linux", architecture: "x64", version: "4.9.125-linuxkit" }, platform: "Node.js v8.9.3, LE, mongodb-core: 3.2.7" }
b-combined |
b-combined | ====================================================================================================
b-combined |
b-combined | (Run Starting)
b-combined |
b-combined | ┌────────────────────────────────────────────────────────────────────────────────────────────────┐
b-combined | │ Cypress: 3.4.1 │
b-combined | │ Browser: Chrome 75 │
b-combined | │ Specs: 1 found (analytics_spec.js) │
b-combined | │ Searched: cypress/integration/analytics_spec.js │
b-combined | └────────────────────────────────────────────────────────────────────────────────────────────────┘
b-combined |
b-combined |
b-combined | ────────────────────────────────────────────────────────────────────────────────────────────────────
b-combined |
b-combined | Running: analytics_spec.js... (1 of 1)
b-combined |
b-combined |
b-combined | Analytics
b-combined | (node:212) DeprecationWarning: collection.remove is deprecated. Use deleteOne, deleteMany, or bulkWrite instead.
b-combined | (node:212) DeprecationWarning: collection.update is deprecated. Use updateOne, updateMany, or bulkWrite instead.
✓ displays listings on the side bar lazily for upcoming events (6565ms)
b-combined | user disconnected
b-combined | user disconnected
✓ displays listings on the side bar lazily for archived events (4227ms)
b-combined | user disconnected
b-combined | user disconnected
✓ allows the user to click between upcoming and archived (3456ms)
b-combined | user disconnected
b-combined | user disconnected
b-combined | user disconnected
b-combined | (node:30) DeprecationWarning: Mongoose: `findOneAndUpdate()` and `findOneAndDelete()` without the `useFindAndModify` option set to false are deprecated. See: https://mongoosejs.com/docs/deprecations.html#-findandmodify-
✓ updates prediction and view count (9194ms)
b-combined | user disconnected
b-combined | user disconnected
b-combined | user disconnected
b-combined | user disconnected
✓ takes users to the correct routes (8759ms)
b-combined |
b-combined |
b-combined | 5 passing (32s)
b-combined |
b-combined |
b-combined | (Results)
b-combined |
b-combined | ┌─────────────────────────────────┐
b-combined | │ Tests: 5 │
b-combined | │ Passing: 5 │
b-combined | │ Failing: 0 │
b-combined | │ Pending: 0 │
b-combined | │ Skipped: 0 │
b-combined | │ Screenshots: 0 │
b-combined | │ Video: false │
b-combined | │ Duration: 32 seconds │
b-combined | │ Spec Ran: analytics_spec.js │
b-combined | └─────────────────────────────────┘
b-combined |
b-combined |
b-combined | ====================================================================================================
b-combined |
b-combined | (Run Finished)
b-combined |
b-combined |
b-combined | Spec Tests Passing Failing Pending Skipped
b-combined | ┌────────────────────────────────────────────────────────────────────────────────────────────────┐
b-combined | │ ✔ analytics_spec.js 00:32 5 5 - - - │
b-combined | └────────────────────────────────────────────────────────────────────────────────────────────────┘
b-combined | All specs passed! 00:32 5 5 - - -
b-combined |
b-combined | user disconnected
b-combined | Mongoose disconnected
b-db | 2019-12-13T11:28:53.042+0000 I NETWORK [conn13] end connection 172.22.0.3:33352 (6 connections now open)
b-db | 2019-12-13T11:28:53.042+0000 I NETWORK [conn11] end connection 172.22.0.3:33348 (5 connections now open)
b-db | 2019-12-13T11:28:53.042+0000 I NETWORK [conn14] end connection 172.22.0.3:33354 (4 connections now open)
b-combined | Mongoose disconnected through app shutdown
b-db | 2019-12-13T11:28:53.065+0000 I NETWORK [conn12] end connection 172.22.0.3:33350 (3 connections now open)
b-combined | TEST ENDED WITH EXIT CODE OF: 0 ===========================
b-combined | EXITING SCRIPT WITH EXIT CODE OF: 0 =====================================
b-db | 2019-12-13T11:28:53.204+0000 I NETWORK [conn9] end connection 172.22.0.3:33344 (2 connections now open)
b-db | 2019-12-13T11:28:53.205+0000 I NETWORK [conn8] end connection 172.22.0.3:33342 (1 connection now open)
b-db | 2019-12-13T11:28:53.205+0000 I NETWORK [conn10] end connection 172.22.0.3:33346 (0 connections now open)
b-combined exited with code 0
Aborting on container exit...
Stopping b-combined ... done
Stopping b-db ... done
0
I expect my init.sh script to be run once but as you can see from the above output, docker-compose runs my init.sh script twice.
I've pulled out the following snippets from the above output to demonstrate that the init.sh script is indeed being run twice:
172.22.0.3:33094 (3 connections now open)
b-combined | user disconnected
b-combined | TEST ENDED WITH EXIT CODE OF: 0 ===========================
b-combined | EXITING SCRIPT WITH EXIT CODE OF: 0 =====================================
...
172.22.0.3:33350 (3 connections now open)
b-combined | TEST ENDED WITH EXIT CODE OF: 0 ===========================
b-combined | EXITING SCRIPT WITH EXIT CODE OF: 0
Why is this happening and how can I ensure docker-compose runs my init.sh script once?
Fixed by removing restart: unless-stopped from docker-compose.yml file.
I am trying to install Kubectl but when I type this in the terminal :
kubectl get pods --namespace knative-serving -w
I got this :
NAME READY STATUS RESTARTS AGE
activator-69b8474d6b-jvzvs 2/2 Running 0 2h
autoscaler-6579b57774-cgmm9 2/2 Running 0 2h
controller-66cd7d99df-q59kl 0/1 Pending 0 2h
webhook-6d9568d-v4pgk 1/1 Running 0 2h
controller-66cd7d99df-q59kl 0/1 Pending 0 2h
controller-66cd7d99df-q59kl 0/1 Pending 0 2h
controller-66cd7d99df-q59kl 0/1 Pending 0 2h
controller-66cd7d99df-q59kl 0/1 Pending 0 2h
controller-66cd7d99df-q59kl 0/1 Pending 0 2h
controller-66cd7d99df-q59kl 0/1 Pending 0 2h
I don't understand why controller-66cd7d99df-q59kl is still pending.
When I tried this : kubectl describe pods -n knative-serving controller-66cd7d99df-q59kl I got this :
Name: controller-66cd7d99df-q59kl
Namespace: knative-serving
Node: <none>
Labels: app=controller
pod-template-hash=66cd7d99df
Annotations: sidecar.istio.io/inject=false
Status: Pending
IP:
Controlled By: ReplicaSet/controller-66cd7d99df
Containers:
controller:
Image: gcr.io/knative-releases/github.com/knative/serving/cmd/controller#sha256:5a5a0d5fffe839c99fc8f18ba028375467fdcd83cbee9c7015c1a58d01ca6929
Port: 9090/TCP
Limits:
cpu: 1
memory: 1000Mi
Requests:
cpu: 100m
memory: 100Mi
Environment: <none>
Mounts:
/etc/config-logging from config-logging (rw)
/var/run/secrets/kubernetes.io/serviceaccount from controller-token-d9l64 (ro)
Conditions:
Type Status
PodScheduled False
Volumes:
config-logging:
Type: ConfigMap (a volume populated by a ConfigMap)
Name: config-logging
Optional: false
controller-token-d9l64:
Type: Secret (a volume populated by a Secret)
SecretName: controller-token-d9l64
Optional: false
QoS Class: Burstable
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 40s (x98 over 2h) default-scheduler 0/1 nodes are available: 1 Insufficient cpu.
Please consider the comments above: you have kubectl installed correctly (it's working) and kubectl describe pod/<pod> would help...
But, the information you provide appears sufficient for an answer:
FailedScheduling because of Insufficient cpu
The pod that you show (one of several) requests:
cpu: 1
memory: 1000Mi
The cluster has insufficient capacity to deploy this pod (and apparently the others).
You should increase the number (and|or size) of the nodes in your cluster to accommodate the capacity needed for the pods.
You needn't delete these pods because, once the cluster's capacity increases, you should see these pods deploy successfully.
Please verify your cpu resources by running:
kubectl get nodes
kubectl describe nodes (your node)
take a look also for all information related to:
Capacity:
cpu:
Allocatable:
cpu:
CPU Requests, CPU Limits information can be helpful