@thungrac43 vì mình cũng khá tò mò vấn đề này muốn xem thử có đúng trên Gitlab CI chạy cũng giống mình thường như mình nghĩ, nên mình đã demo luôn cho bạn.

Link repo demo ở đây

Ở link trên mình dùng luôn project trong bài này, mount volume bằng đường dẫn tương đối. Và MongoDB vẫn chạy ngon với non-root user mà không phải sửa gì, mình có test gọi API ở trong pipeline để chắc chắn MongoDB đã chạy ngon, ko khác gì bình thường.

Có 1 sự bất ngờ nhẹ: ko hiểu sao mặc dù folder mount volume ở môi trường ngoài .docker/data/db ban đầu là của root sẵn, nhưng khi chạy lên thì MongoDB vẫn có thể ghi vào đó được với quyền của user 1000:1000. Bình thường đáng ra là phải báo lỗi permission (vì mongo chạy với non-root user).Mình chưa hiểu sao Gitlab Runner lại "thông minh" vậy . Nhưng dù sao nếu báo lỗi thì mình cũng đã có 1 dòng comment chown sẵn cho bạn, nếu có báo lỗi bạn bỏ comment dòng đó là được

Bài viết rất hay. Đã follow. Mong chờ bài tiếp. Tks

Message Format và Monitor Queue có thể xếp vào mục cần lưu ý khi sử dụng. Tuy nhiên, việc xây dựng hệ thống Message Format hay Monitor Queue có thể gây ra những khó khăn nhất định, đặc biệt là monitor. "Khi xây dựng hệ thống xử lý bất đồng bộ dựa trên message thì việc monitor có tính chất cốt tử", ngoài monitor queue thì còn phải kết hợp với monitor quá trình xử lý một message, không có một hệ thống monitor tốt thì không thể chạy trên môi trường production.

Bạn copy tài liệu này ở đâu? Đã xin ý kiến author chưa?

thank

@thungrac43, bạn đọc lại phần cuối của bài Docker non-root nhé,

Permission không bị ảnh hưởng bởi user ngừoi chạy docker-compose up (như ban đầu mình nghĩ), mà ban đầu bên ngoài nó có permission nào thì mount vào trong container sẽ có permission như vậy.

Mình cũng chưa bao giờ dùng tới biến môi trường CI_PROJECT_DIR.

Lúc chạy bạn cứ làm sao chắc chắn là folder - nơi bạn mount volume có quyền bằng với user trong container là được. Do vậy dùng đường dẫn tương đối hay tuyệt đối cũng chỉ là tuỳ chọn

Và nếu bạn vẫn không hiểu thì mình rất sẵn lòng setup 1 pipeline demo về việc này (dùng đường dẫn tương đối)

@maitrungduc1410 trong bài docker non root bạn chạy docker-compose up tại thư mục đã tạo sẵn. Bạn thử inspect container sẽ thấy tham số

CI_PROJECT_DIR chính là thư mục bạn đang đứng. Khi đó bạn đã set permission cho folder này rồi. Nên user trong db có thể truy cập được.

Tuy vậy trong bài này bạn chạy docker-compose up qua gitlab-runner user (thường là root). Khi đó

CI_PROJECT_DIR="/builds/maitrungduc1410/cicd-auto-deploy"

và user trong db ko có quyền truy cập vào đây => service không khởi động được.

Cảm ơn em

Sư phụ xin hãy nhận đệ tử một lạy

Bạn đang chạy gitlab runner với user james (1000:1000) và container db cũng set user 1000:1000 ...

@thungrac43 thì tất nhiên rồi bạn, đây không phải là điều kiện lý tưởng mà là điều kiện cần mà mình đã nói rất rõ ở bài chạy container với non root user đó là user trong container phải có quyền bằng với user môi trường ngoài - người sở hữu folder mount volume.

và nó làm bạn Khôi lầm tưởng là Viết tay :v

@ngankim attempt thì thêm được điều kiện nhưng phủ định thì theo mình nghĩ là không

Good job

@duong.manh.hoang cảm ơn bạn. Mình đang ko hỏi về cách override.
Câu hỏi của mình là khi dùng hàm attempt. Thì có cách nào thêm condition cho nó, để nó check theo câu truy vấn kia ko

where email = $email AND password = $pw AND role in ('Admin', 'Admod') 

Và

where email = $email AND password = $pw AND role != 'ABC' 

@maitrungduc1410 nếu bạn dùng đường dẫn tương đối. ở job jest tại bước

• docker-compose up -d

thì container db sẽ không khởi động được vì ko có permission trên thư mục /data/db

Bạn đang chạy gitlab runner với user james (1000:1000) và container db cũng set user 1000:1000 là điều kiện lý tưởng nên mới được. Bạn thử tạo 1 user mới khác james và chạy db với user này sẽ lỗi ngay.

sẽ sớm có nhé bạn :v

Với các bạn nhà nghèo như mình có thể triển khai demo bằng máy ảo (vmware) như sau:

• Máy ảo vmware cài docker, docker-compose...init thư mục, setup user non root, tạo ssh key như bài viết.
• Docker sẽ tạo ra 1 network interface tên docker0 có ip 172.17.0.1, tất cả các containers sẽ ssh được vào ip này.

Cảm ơn bạn đã góp ý nhưng mình chưa rõ ý của bạn lắm. Bạn có thể giúp đỡ mình chỉ ra chỗ sai để mình update bài viết không?.

Những gì mình nghiên cứu được là một coroutine được phóng trong GlobalScope, nó sử dụng Dispatchers.Default tức là sử dụng shared background pool of threads nên mình viết là // chạy một coroutine trên background thread. Có thể mình bị miss ở đâu đó. Mong bạn chỉ dẫn thêm.

The default dispatcher that is used when coroutines are launched in GlobalScope is represented by Dispatchers.Default and uses a shared background pool of threads, so launch(Dispatchers.Default) { ... } uses the same dispatcher as GlobalScope.launch { ... }.

Nguồn: https://kotlinlang.org/docs/reference/coroutines/coroutine-context-and-dispatchers.html

@thungrac43

Sao bạn phải phức tạp hoá vấn đề lên vậy

Khi chạy CICD, Gitlab Runner sẽ tự động clone code về folder hiện tại mà nó làm việc, ta không cần biết chính xác folder đó tên là gì, vì mount volume ta dùng đường dẫn tương đối trỏ về folder hiện tại.

Ở docker-compose.yml khi mount volume, thì chỉ đường dẫn ở trong container (phía bên phải) phải là đường dẫn tuyệt đối, còn đường dẫn phía môi trường ngoài thì có thể là tương đối hoặc tuyệt đối:

volumes:
      - /home/docker/tmp/.docker/data/db:/data/db # tuyệt đối
      - .docker/data/db:/data/db # tương đối

Cả 2 cách đều được.

GlobalScope.launch { // chạy một coroutine trên background thread

• Bạn xem lại xem chỗ này comment có đúng không nha. Nếu chưa chắc chắn thì có thể xem lại:

• https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/launch.html
• https://kotlinlang.org/docs/reference/coroutines/basics.html