Cách khắc phục sự cố thường gặp với server CoreOS của bạn
CoreOS giới thiệu một số công nghệ thú vị giúp xây dựng hệ thống phân tán dễ dàng. Tuy nhiên, những công cụ này có thể không quen thuộc với user mới và có những đặc điểm riêng. Một trong những vấn đề chính là có nhiều lớp trừu tượng tại nơi làm việc và có thể khó xác định nơi xảy ra vấn đề.Trong hướng dẫn này, ta sẽ xem xét một số quy trình khắc phục sự cố cơ bản để làm việc với các server CoreOS, các containers Docker mà chúng chạy và các công cụ quản lý dịch vụ kéo một số phần khác nhau lại với nhau.
Gỡ lỗi file cấu hình cloud của bạn
Một trong những vấn đề phổ biến nhất mà user CoreOS mới và có kinh nghiệm gặp phải khi một cụm không xuất hiện chính xác là file cấu hình cloud không hợp lệ.
CoreOS yêu cầu file cấu hình cloud phải được chuyển vào server của bạn khi tạo. Nó sử dụng thông tin có trong file này để tự khởi động và khởi tạo hoặc tham gia một cụm hiện có. Nó cũng khởi động các dịch vụ thiết yếu và có thể cấu hình các thông tin cơ bản của hệ thống như user và group .
Một số điều cần kiểm tra với file cấu hình cloud của bạn:
- Nó có bắt đầu bằng “# cloud-config” không? : Mọi file cloud-config được chuyển vào phải bắt đầu bằng “# cloud-config” đứng riêng trên dòng đầu tiên. Trong khi đây thường là một comment bị bỏ qua trong YAML, trong trường hợp này, dòng này được sử dụng để báo hiệu cho hệ thống cloud init rằng điều này chứa dữ liệu cấu hình.
- Tệp của bạn có chứa YAML hợp lệ không? : Các file cấu hình cloud được viết bằng YAML, một định dạng tuần tự hóa dữ liệu tập trung vào khả năng đọc. Nếu bạn đang gặp sự cố, hãy dán cấu hình cloud của bạn vào trình xác thực YAML trực tuyến. Tệp của bạn không được có lỗi. CoreOS cung cấp một công cụ hữu ích có thể kiểm tra cú pháp của file cấu hình cloud của bạn, Cloud-Config Validator .
- Bạn có đang sử dụng mã thông báo khám phá mới không? : Địa chỉ khám phá theo dõi dữ liệu trên máy của bạn ngay cả khi toàn bộ cụm bị ngừng hoạt động. Việc đăng ký khám phá sẽ không thành công khi bạn khởi động bằng mã thông báo cũ, đặc biệt nếu bạn đã đăng ký cùng một địa chỉ IP trước đó. Sử dụng mã thông báo khám phá mới mỗi khi bạn bắt đầu một cụm để tránh sự cố này.
- Bạn đang bắt đầu đội xe và các dịch vụ vvd? : Hai dịch vụ phải bắt đầu để cụm của bạn hoạt động chính xác là
fleetvàetcd. Bạn nên xem hướng dẫn của ta về cách chạy một cụm CoreOS trên DigitalOcean để có file cấu hình cloud cơ bản đáp ứng các yêu cầu tối thiểu này.
Bạn chỉ có thể chuyển vào file cấu hình cloud khi máy được tạo, vì vậy nếu bạn đã mắc lỗi, hãy hủy version server và bắt đầu lại (với mã thông báo mới, trong hầu hết các trường hợp).
Khi bạn đã khá chắc chắn rằng bản thân file cấu hình cloud là đúng, bước tiếp theo là đăng nhập vào server lưu trữ đảm bảo rằng file được xử lý chính xác.
Điều này sẽ dễ dàng trong hầu hết các trường hợp vì trên DigitalOcean, bạn được yêu cầu thêm khóa ssh vào server trong quá trình tạo. Điều này nghĩa là bạn thường có thể ssh vào server để khắc phục sự cố mà không gặp sự cố.
Đăng nhập thông qua Control panel DigitalOcean
Tuy nhiên, có những thời điểm nhất định khi cấu hình cloud của bạn có thể thực sự ảnh hưởng đến tính khả dụng của mạng trên server của bạn sau khi chạy . Trong trường hợp này, bạn sẽ phải đăng nhập thông qua console DigitalOcean. Điều này gây ra một vấn đề, vì không có password nào được đặt trên hình ảnh CoreOS theo mặc định, vì lý do bảo mật.
Để làm việc này, bạn phải tạo lại server với một file cloud -config mới, trong đó có một mục password cho core dùng. Do yêu cầu giải trí, điều này có thể sẽ chỉ hữu ích nếu bạn thường xuyên thấy vấn đề này và muốn có thêm thông tin. Bạn có thể cần thêm thông tin password vào tất cả các file cấu hình cloud của bạn như một phương pháp chung để bạn có thể khắc phục sự cố. Bạn có thể bỏ đặt password theo cách thủ công sau khi xác minh kết nối của bạn .
Mật khẩu phải ở dạng băm. Bạn có thể tạo ra một số cách khác nhau tùy thuộc vào phần mềm bạn có . Bất kỳ cách nào sau đây sẽ hoạt động, vì vậy hãy sử dụng tùy chọn nào phù hợp nhất với bạn:
mkpasswd --method=SHA-512 --rounds=4096 openssl passwd -1 python -c "import crypt, getpass, pwd; print crypt.crypt('password', '\$6\$SALT\$')" perl -e 'print crypt("password","\$6\$SALT\$") . "\n"' Khi bạn đã có băm, bạn có thể thêm một phần mới vào cấu hình cloud của bạn (bên ngoài phần “coreos”), được gọi là users để đặt thông tin này:
#cloud-config users: - name: core passwd: hashed_password coreos: . . . Xác thực cú pháp YAML của bạn , sau đó sử dụng cấu hình cloud mới này khi tạo lại server . Sau đó, bạn có thể sử dụng password bạn đã chọn để đăng nhập thông qua console DigitalOcean.
Kiểm tra Server Cá nhân
Khi bạn đã đăng nhập, có một số điều bạn nên kiểm tra để xem liệu cấu hình cloud của bạn có được xử lý chính xác hay không.
Kiểm tra lỗi trong các dịch vụ thiết yếu
Một cách dễ dàng để bắt đầu là hỏi fleetctl xem nó biết về máy móc gì. Nếu điều này trả về mà không có lỗi, điều đó nghĩa là fleet và etcd đã được khởi động đúng cách và chúng đang giao tiếp với các server khác.
fleetctl list-machines Nếu bạn gặp lỗi ở đây, có một số điều bạn nên xem xét. Một lỗi phổ biến trông giống như sau:
2014/09/18 17:10:50 INFO client.go:278: Failed getting response from http://127.0.0.1:4001/: dial tcp 127.0.0.1:4001: connection refused 2014/09/18 17:10:50 ERROR client.go:200: Unable to get result for {Get /_coreos.com/fleet/machines}, retrying in 100ms 2014/09/18 17:10:50 INFO client.go:278: Failed getting response from http://127.0.0.1:4001/: dial tcp 127.0.0.1:4001: connection refused 2014/09/18 17:10:50 ERROR client.go:200: Unable to get result for {Get /_coreos.com/fleet/machines}, retrying in 200ms Vì điều này đại diện cho một chồng các thành phần khác nhau chồng lên nhau, ta hãy bắt đầu ở cấp cao nhất và làm việc xuống. Kiểm tra dịch vụ của fleet để xem nó cung cấp cho ta những lỗi nào:
systemctl status -l fleet ● fleet.service - fleet daemon Loaded: loaded (/usr/lib64/systemd/system/fleet.service; static) Drop-In: /run/systemd/system/fleet.service.d └─20-cloudinit.conf Active: active (running) since Thu 2014-09-18 17:10:50 UTC; 2min 26s ago Main PID: 634 (fleetd) CGroup: /system.slice/fleet.service └─634 /usr/bin/fleetd Sep 18 17:13:07 dumb1 fleetd[634]: INFO client.go:278: Failed getting response from http://localhost:4001/: dial tcp 127.0.0.1:4001: connection refused Sep 18 17:13:07 dumb1 fleetd[634]: ERROR client.go:200: Unable to get result for {Update /_coreos.com/fleet/machines/795de101bcd24a3a96aa698f770f0074/object}, retrying in 800ms Sep 18 17:13:08 dumb1 fleetd[634]: INFO client.go:278: Failed getting response from http://localhost:4001/: dial tcp 127.0.0.1:4001: connection refused Như bạn thấy , dịch vụ đang chạy, nhưng nó không thể kết nối với cổng 4001 , đó là cổng etcd . Điều này cho thấy rằng vấn đề có thể là với etcd .
Đối với mỗi dịch vụ thiết yếu của ta , ta nên kiểm tra trạng thái và log . Cách chung để làm điều này là:
systemctl status -l service journalctl -b -u service Lệnh "trạng thái" cung cấp cho ta trạng thái của dịch vụ và một vài dòng log cuối cùng. Lệnh log cho phép ta truy cập vào các log đầy đủ.
Nếu ta thử những điều này với etcd tiếp theo, ta có thể thấy rằng dịch vụ etcd không chạy trong trường hợp của ta :
systemctl status -l etcd ● etcd.service - etcd Loaded: loaded (/usr/lib64/systemd/system/etcd.service; static) Drop-In: /run/systemd/system/etcd.service.d └─20-cloudinit.conf Active: activating (auto-restart) (Result: exit-code) since Thu 2014-09-18 17:17:03 UTC; 9s ago Process: 938 ExecStart=/usr/bin/etcd (code=exited, status=1/FAILURE) Main PID: 938 (code=exited, status=1/FAILURE) Sep 18 17:17:03 dumb1 systemd[1]: etcd.service: main process exited, code=exited, status=1/FAILURE Sep 18 17:17:03 dumb1 systemd[1]: Unit etcd.service entered failed state. Nếu ta kiểm tra log etcd , ta sẽ thấy thông tin như sau:
journalctl -b -u etcd Sep 18 17:21:27 dumb1 systemd[1]: Starting etcd... Sep 18 17:21:27 dumb1 systemd[1]: Started etcd. Sep 18 17:21:27 dumb1 etcd[1160]: [etcd] Sep 18 17:21:27.966 INFO | The path /var/lib/etcd/log is in btrfs Sep 18 17:21:27 dumb1 etcd[1160]: [etcd] Sep 18 17:21:27.967 INFO | Set NOCOW to path /var/lib/etcd/log succeeded Sep 18 17:21:27 dumb1 etcd[1160]: [etcd] Sep 18 17:21:27.967 INFO | Discovery via https://discovery.etcd.io using prefix /. Sep 18 17:21:28 dumb1 etcd[1160]: [etcd] Sep 18 17:21:28.422 WARNING | Discovery encountered an error: invalid character 'p' after top-level value Sep 18 17:21:28 dumb1 etcd[1160]: [etcd] Sep 18 17:21:28.423 WARNING | 795de101bcd24a3a96aa698f770f0074 failed to connect discovery service[https://discovery.etcd.io/]: invalid character 'p' after top-level value Sep 18 17:21:28 dumb1 etcd[1160]: [etcd] Sep 18 17:21:28.423 CRITICAL | 795de101bcd24a3a96aa698f770f0074, the new instance, must register itself to discovery service as required Sep 18 17:21:28 dumb1 systemd[1]: etcd.service: main process exited, code=exited, status=1/FAILURE Sep 18 17:21:28 dumb1 systemd[1]: Unit etcd.service entered failed state. Dòng được đánh dấu cho thấy rằng version cụ thể này không có mã thông báo khám phá.
Kiểm tra hệ thống file để xem các file cấu hình được tạo bởi Cloud-Config
Điều tiếp theo cần kiểm tra là file dịch vụ nào được tạo bởi cấu hình cloud .
Khi máy CoreOS của bạn xử lý file cấu hình cloud , nó tạo ra các file đơn vị systemd sơ khai mà nó sử dụng để khởi động fleet và etcd Để xem các file cấu hình systemd đã được tạo và đang được sử dụng để khởi động các dịch vụ của bạn, hãy thay đổi folder nơi chúng được thả:
cd /run/systemd/system ls -F etcd.service.d/ fleet.service.d/ oem-cloudinit.service Bạn có thể thấy file oem-cloudinit.service tổng quát oem-cloudinit.service lý tự động và các folder có thông tin dịch vụ trong đó. Ta có thể xem thông tin mà dịch vụ etcd của ta đang bắt đầu bằng lệnh :
cat etcd.servicd.d/20-cloudinit.conf [Service] Environment="ETCD_ADDR=10.132.247.162:4001" Environment="ETCD_DISCOVERY=https://discovery.etcd.io/" Environment="ETCD_NAME=795de101bcd24a3a96aa698f770f0074" Environment="ETCD_PEER_ADDR=10.132.247.162:7001" Đây là một file đơn vị systemd sơ khai được sử dụng để thêm thông tin bổ sung vào dịch vụ khi nó được khởi động. Như bạn thấy ở đây, địa chỉ ETCD_DISCOVERY trùng với lỗi ta tìm thấy trong log : không có mã thông báo khám phá nào được nối vào cuối. Ta cần làm lại máy của bạn bằng cách sử dụng cấu hình cloud với mã thông báo khám phá hợp lệ.
Bạn có thể nhận được thông tin tương tự về fleet bằng lệnh :
cat fleet.service.d/20-cloudinit.conf [Service] Environment="FLEET_METADATA=region=nyc,public_ip=104.131.1.89" Environment="FLEET_PUBLIC_IP=10.132.247.162" Ở đây, ta có thể thấy rằng fleet đã được đưa ra một số thông tin metadata trong cloud -config. Điều này được dùng để lập lịch khi bạn tạo file đơn vị dịch vụ.
Kiểm tra quyền truy cập vào dịch vụ metadata
Tệp cấu hình cloud thực tế được cung cấp khi server CoreOS được tạo bằng DigitalOcean được lưu trữ bằng dịch vụ metadata . Nếu bạn không thể tìm thấy bất kỳ bằng chứng nào về cấu hình cloud của bạn trên server của bạn , thì có thể là không thể lấy thông tin từ dịch vụ metadata DigitalOcean.
Từ bên trong server của bạn, hãy nhập:
curl -L 169.254.169.254/metadata/v1 id hostname user-data vendor-data public-keys region interfaces/ dns/ Bạn phải bao gồm -L để theo dõi chuyển hướng. Địa chỉ 169.254.169.254 sẽ được sử dụng cho mọi server , vì vậy bạn không nên sửa đổi địa chỉ này. Điều này hiển thị cho bạn các trường metadata và folder chứa thông tin về server của bạn. Nếu bạn không thể truy cập điều này từ bên trong server CoreOS DigitalOcean của bạn , bạn có thể cần mở một phiếu hỗ trợ.
Bạn có thể truy vấn URL này để biết thông tin về server của bạn . Bạn có thể khám phá từng mục nhập tại đây bằng các lệnh curl bổ sung, nhưng lệnh chứa file cấu hình cloud là trường user-data :
curl -L 169.254.169.254/metadata/v1/user-data #cloud-config users: - name: core passwd: $6$CeKTMyfClO/CPSHB$02scg00.FnwlEYdq/oXiXoohzvvlY6ykUck1enMod7VKJrzyGRAtZGziZh48LNcECu/mtgPZpY6aGCoj.h4bV1 coreos: etcd: # generated token from https://discovery.etcd.io/new discovery: https://discovery.etcd.io/ # multi-region and multi-cloud deployments need to use $public_ipv4 addr: $private_ipv4:4001 peer-addr: $private_ipv4:7001 fleet: public-ip: $private_ipv4 metadata: region=nyc,public_ip=$public_ipv4 units: - name: etcd.service command: start - name: fleet.service command: start Nếu bạn có thể đọc cấu hình cloud của bạn từ vị trí này, điều đó nghĩa là server của bạn có khả năng đọc dữ liệu cấu hình cloud và phải triển khai các hướng dẫn của nó khi khởi động server .
Khắc phục sự cố Các vấn đề khác với Server CoreOS
Nếu bạn cần gỡ lỗi thêm, bạn có thể nhanh chóng phát hiện ra rằng CoreOS chứa một cài đặt cơ sở rất tối thiểu. Vì nó mong đợi tất cả phần mềm được chạy trong các container , nó không bao gồm một số chương trình tiện ích cơ bản nhất.
May mắn là các nhà phát triển CoreOS cung cấp một giải pháp hữu ích cho vấn đề này. Bằng cách sử dụng tập lệnh “hộp công cụ” có trong mỗi server , bạn có thể khởi động containers Fedora với quyền truy cập vào hệ thống server . Từ bên trong containers này, bạn có thể cài đặt bất kỳ tiện ích nào cần thiết để gỡ lỗi server .
Để khởi động nó, chỉ cần sử dụng lệnh toolbox :
toolbox Thao tác này sẽ kéo hình ảnh Fedora mới nhất xuống và đưa bạn vào một dòng lệnh trong containers . Nếu bạn thực hiện một số kiểm tra nhanh, bạn sẽ nhận ra rằng bạn có quyền truy cập vào mạng của hệ thống server :
ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 04:01:28:7c:39:01 brd ff:ff:ff:ff:ff:ff inet 169.254.180.43/16 brd 169.254.255.255 scope link eth0 valid_lft forever preferred_lft forever . . . Bạn cũng có toàn quyền truy cập vào các quy trình của server :
ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.1 106024 4912 ? Ss 17:10 0:04 /usr/lib/systemd/systemd --switched-root --system --deserialize 19 root 2 0.0 0.0 0 0 ? S 17:10 0:00 [kthreadd] root 3 0.0 0.0 0 0 ? S 17:10 0:00 [ksoftirqd/0] root 5 0.0 0.0 0 0 ? S< 17:10 0:00 [kworker/0:0H] root 6 0.0 0.0 0 0 ? S 17:10 0:00 [kworker/u4:0] root 7 0.0 0.0 0 0 ? S 17:10 0:00 [rcu_sched] root 8 0.0 0.0 0 0 ? S 17:10 0:00 [rcu_bh] . . . Bạn có thể cài đặt bất kỳ công cụ nào bạn cần trong môi trường này. Ví dụ: ta có thể cài đặt htop , một bản sao hàng đầu với các tính năng bổ sung, bằng cách sử dụng trình quản lý gói Fedora:
yum install htop -y && htop Thao tác này sẽ hiển thị trình theo dõi quá trình với tất cả các quá trình của server đã được tải.
Để thoát khỏi môi trường containers , hãy nhập “exit” hoặc nhấn CTRL-] nhanh ba lần. Bạn sẽ được đưa trở lại phiên shell của server .
Dịch vụ khắc phục sự cố từ bất kỳ server nào
Một lĩnh vực khác mà bạn có thể cần khắc phục sự cố là các dịch vụ thực tế bạn đang chạy. Bởi vì ta có fleet và fleetctl để quản lý các dịch vụ của ta theo cụm rộng, bước đầu tiên của ta có thể được preformed trên bất kỳ các server trong cluster của ta .
Ta nên bắt đầu bằng cách tìm hiểu về tình trạng dịch vụ của bạn, cả từ khía cạnh fleet và từ các server riêng lẻ đã được chỉ định để điều hành từng dịch vụ. Công cụ fleetctl cung cấp cho ta các lệnh để dễ dàng lấy thông tin này.
Trước tiên, hãy tìm hiểu cách fleet nhìn thấy trạng thái dịch vụ bằng lệnh :
fleetctl list-unit-files UNIT HASH DSTATE STATE TARGET apache-discovery@4444.service 06d78fb loaded loaded 04856ec4.../10.132.249.212 apache-discovery@7777.service 06d78fb loaded loaded 197a1662.../10.132.249.206 apache-discovery@8888.service 06d78fb loaded loaded e3ca8fd3.../10.132.252.37 apache@4444.service 0f7f53b launched launched 04856ec4.../10.132.249.212 apache@7777.service 0f7f53b launched launched 197a1662.../10.132.249.206 apache@8888.service 0f7f53b launched launched e3ca8fd3.../10.132.252.37 nginx_lb.service c8541af launched launched 96ec72cf.../10.132.248.177 Điều này sẽ cung cấp cho bạn một cái nhìn tổng quan về tất cả các dịch vụ mà fleet biết về. Đầu ra này có một số thông tin rất quan trọng. Ta hãy xem xét.
- UNIT : Đây là tên của đơn vị. Trong trường hợp của ta , sáu dịch vụ hàng đầu là tất cả các đơn vị cá thể (tìm thêm về các mẫu và version tại đây) và phần dưới cùng dường như là một cá thể tĩnh. Đây là những tên mà ta có thể sử dụng để đưa ra các lệnh ảnh hưởng đến từng dịch vụ này.
- HASH : đây là mã băm của file đơn vị được sử dụng để kiểm soát dịch vụ này. Như bạn thấy , tất cả các version
apache-discoveryđều được tạo ra từ cùng một file mẫu. Các cá thểapacheđều được sinh ra từ một version khác. Điều này có thể hữu ích để xem liệu bất kỳ dịch vụ nào của bạn đang có biểu hiện lạ bằng cách sử dụng file đơn vị lỗi thời. - DSTATE : Đây là trạng thái mong muốn của đơn vị. Khi bạn ra lệnh cho
fleetctlđể thay đổi trạng thái của một đơn vị, cột này sẽ thay đổi để phản ánh trạng thái mong muốn cho đơn vị đó. - STATE : Đây là trạng thái thực tế của đơn vị, được biết đến với
fleet. Nếu điều này khác với DSTATE, điều đó có thể nghĩa là một hoạt động đã không thành công. - MỤC TIÊU : Máy đã được lên lịch để chạy dịch vụ này. Điều này sẽ khả dụng khi một đơn vị được chạy hoặc được tải. Nó chứa ID máy và địa chỉ IP của máy.
Như bạn thấy , có khá nhiều thông tin có thể giúp bạn gỡ lỗi.
Tuy nhiên, đây không phải là nơi quan trọng duy nhất để kiểm tra. Điều quan trọng là nhận ra rằng có những lúc fleet sẽ không đồng ý với version systemd local của máy về trạng thái của một dịch vụ. Điều này có thể xảy ra vì nhiều lý do, chẳng hạn như nếu một thiết bị khởi động hoặc dừng một thiết bị khác trong nội bộ.
Để nhận thông tin về trạng thái của từng dịch vụ, được lấy từ version systemd của server đang chạy dịch vụ đó, hãy sử dụng lệnh list-units thay thế:
fleetctl list-units UNIT MACHINE ACTIVE SUB apache-discovery@4444.service 04856ec4.../10.132.249.212 active running apache-discovery@7777.service 197a1662.../10.132.249.206 active running apache-discovery@8888.service e3ca8fd3.../10.132.252.37 active running apache@4444.service 04856ec4.../10.132.249.212 active running apache@7777.service 197a1662.../10.132.249.206 active running apache@8888.service e3ca8fd3.../10.132.252.37 active running nginx_lb.service 96ec72cf.../10.132.248.177 active running Ở đây, ta có thể thấy rằng tất cả các dịch vụ được liệt kê là đang chạy. Điều này không đồng ý với thông tin mà list-unit-files hiển thị. Đó là bởi vì mỗi dịch vụ apache chạy dịch vụ apache-discovery liên quan mà không cho fleet biết. Đây không phải là lỗi, nhưng có thể gây nhầm lẫn về trạng thái thực tế của dịch vụ.
Để biết thêm thông tin về bất kỳ dịch vụ nào, bạn có thể sử dụng fleetctl để truy cập systemctl status của hệ thống server và thông tin journalctl -u . Chỉ loại:
fleetctl status service_name ● apache@4444.service - Apache web server service on port 4444 Loaded: loaded (/run/fleet/units/apache@4444.service; linked-runtime) Active: active (running) since Thu 2014-09-18 18:50:00 UTC; 7min ago Process: 3535 ExecStartPre=/usr/bin/docker pull imchairmanm/apache (code=exited, status=0/SUCCESS) Process: 3526 ExecStartPre=/usr/bin/docker rm apache.%i (code=exited, status=0/SUCCESS) Process: 3518 ExecStartPre=/usr/bin/docker kill apache.%i (code=exited, status=0/SUCCESS) Main PID: 3543 (docker) CGroup: /system.slice/system-apache.slice/apache@4444.service └─3543 /usr/bin/docker run -t --name apache.4444 -p 10.132.249.212:4444:80 imchairmanm/apache /usr/sbin/apache2ctl -D FOREGROUND Hoặc đọc log bằng lệnh :
fleetctl journal service_name -- Logs begin at Mon 2014-09-15 14:54:12 UTC, end at Thu 2014-09-18 18:57:51 UTC. -- Sep 17 14:33:20 lala2 systemd[1]: Started Apache web server service on port 4444. Sep 17 14:33:20 lala2 docker[21045]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.10. Set the 'ServerName' directive globally to suppress this message Sep 18 18:49:29 lala2 systemd[1]: Stopping Apache web server service on port 4444... Sep 18 18:49:39 lala2 docker[3500]: apache.4444 Sep 18 18:49:39 lala2 systemd[1]: Stopped Apache web server service on port 4444. Sep 18 18:49:58 lala2 systemd[1]: Starting Apache web server service on port 4444... Sep 18 18:49:58 lala2 docker[3518]: apache.4444 Sep 18 18:49:58 lala2 docker[3526]: apache.4444 Sep 18 18:49:58 lala2 docker[3535]: Pulling repository imchairmanm/apache Sep 18 18:50:00 lala2 systemd[1]: Started Apache web server service on port 4444. Điều này có thể cung cấp một số thông tin tốt về lý do tại sao dịch vụ của bạn không thành công. Ví dụ: nếu file đơn vị của bạn khai báo một phụ thuộc không khả dụng, điều đó sẽ hiển thị ở đây (điều này có thể xảy ra nếu phụ thuộc chưa được tải vào fleet ).
Một lỗi bạn có thể gặp phải khi thực hiện một số lệnh sau là:
Error running remote command: SSH_ AUTH _SOCK environment variable is not set. Verify ssh-agent is running. See https://github.com/coreos/fleet/blob/master/Documentation/using-the-client.md for help. Đây là dấu hiệu cho thấy bạn đã không chuyển tiếp tác nhân user ssh của bạn khi bạn kết nối với server này. Để fleet có được thông tin về các máy khác trong cụm, nó kết nối bằng thông tin đăng nhập SSH mà bạn giữ trên máy tính local của bạn .
Để thực hiện việc này, bạn phải chạy một tác nhân ssh trên máy tính local của bạn và thêm private key của bạn. Bạn có thể thực hiện việc này trên máy tính local của bạn bằng lệnh :
eval $(ssh-agent) ssh-add Identity added: /home/username/.ssh/id_rsa (/home/username/.ssh/id_rsa) Sau khi đại lý ssh của bạn đã được cấp quyền truy cập vào private key của bạn, bạn nên kết nối với server CoreOS của bạn bằng tùy chọn -A để chuyển tiếp thông tin này:
ssh -A core@coreos_host Điều này sẽ cho phép máy bạn sử dụng thông tin đăng nhập của bạn để tạo kết nối với các máy khác trong cụm. Nó là thứ cho phép bạn đọc thông tin systemd từ các thành viên cụm từ xa. Nó cũng cho phép bạn ssh trực tiếp cho các thành viên khác.
Khắc phục sự cố containers từ server đang chạy dịch vụ
Mặc dù bạn có thể nhận được nhiều phần thông tin tuyệt vời chỉ bằng cách sử dụng fleetctl , nhưng đôi khi bạn phải đến server chịu trách nhiệm điều hành dịch vụ để khắc phục sự cố.
Như ta đã nêu ở trên, điều này thật dễ dàng khi bạn đã chuyển tiếp thông tin SSH của bạn khi kết nối. Từ server mà bạn đã kết nối, bạn có thể “nhảy” sang các máy khác bằng cách sử dụng fleetctl . Bạn có thể chỉ định ID máy hoặc đơn giản là tên dịch vụ. Quy trình fleetctl đủ thông minh để biết bạn đang đề cập đến server nào:
fleetctl ssh service_name Điều này sẽ cung cấp cho bạn kết nối ssh đến server được chỉ định để chạy dịch vụ đó. Dịch vụ phải ở trạng thái “đã tải” hoặc “ chạy ” thì dịch vụ này mới hoạt động.
Từ đây, bạn sẽ có quyền truy cập vào tất cả các công cụ khắc phục sự cố local . Ví dụ, bạn có thể nhận được quyền truy cập vào các cài đặt hoàn chỉnh hơn về journalctl cờ mà có thể không được cung cấp thông qua các fleetctl journal lệnh:
journalctl -b --no-pager -u apache@4444 Đến đây, bạn có thể cần khắc phục sự cố Docker. Để xem danh sách các containers đang chạy, hãy nhập:
docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES b68139630337 imchairmanm/apache:latest "/usr/sbin/apache2ct 30 minutes ago Up 30 minutes 10.132.249.212:4444->80/tcp apache.4444 Ta có thể thấy rằng hiện có một containers đang chạy. ID containers được đánh dấu hữu ích cho nhiều hoạt động Docker khác.
Nếu dịch vụ của bạn không khởi động được, containers của bạn sẽ không chạy. Để xem danh sách tất cả các containers , bao gồm cả những containers đã thoát / không thành công, hãy chuyển cờ -a :
docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES b68139630337 imchairmanm/apache:latest "/usr/sbin/apache2ct 31 minutes ago Up 31 minutes 10.132.249.212:4444->80/tcp apache.4444 4389108bff1a imchairmanm/apache:latest "/usr/sbin/apache2ct 28 hours ago Exited (-1) 28 hours ago apache.8888 5af6e4f95642 imchairmanm/lalala:latest "/usr/sbin/apache2ct 3 days ago Exited (-1) 3 days ago apache.7777 Để xem containers cuối cùng đã được bắt đầu, dù trạng thái của nó, bạn có thể sử dụng cờ -l để thay thế:
docker ps -l CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES b68139630337 imchairmanm/apache:latest "/usr/sbin/apache2ct 33 minutes ago Up 33 minutes 10.132.249.212:4444->80/tcp apache.4444 Khi bạn có ID containers của containers bạn đang tìm kiếm, bạn có thể bắt đầu điều tra ở cấp Docker. Trước tiên, bạn có thể xem log :
docker logs container_id Điều này sẽ cung cấp cho bạn thông tin log có thể được thu thập từ containers . Điều này sẽ hoạt động cho dù containers đang chạy hay không. Nếu containers được chạy tương tác (với cờ -i và -t và một phiên shell), toàn bộ phiên sẽ có sẵn trong log .
Bạn có thể nhận được danh sách các quy trình đang chạy cho bất kỳ containers nào đang hoạt động bằng lệnh :
docker top container_id Sinh ra một phiên Shell trong một containers
Một trong những bước hữu ích nhất là thực sự mở một phiên shell trên một containers đang chạy để xem những gì đang diễn ra từ bên trong. Để làm điều này, CoreOS cung cấp một tiện ích có tên là nsenter .
Bộ chứa Docker hoạt động bằng cách cài đặt không gian tên kernel và công cụ này có thể bắt đầu một phiên trong các môi trường này. Bước đầu tiên là lấy PID của containers mà bạn muốn nhập:
PID=$(docker inspect --format {{.State.Pid}} container_id) Bây giờ, bạn có thể mở một phiên shell trong môi trường containers đó bằng lệnh :
sudo nsenter -t $PID -m -u -i -n -p Bạn sẽ được cung cấp một phiên shell trong môi trường containers . Từ đây, bạn có thể xem log hoặc thực hiện bất kỳ thao tác khắc phục sự cố nào cần thiết.
Tùy thuộc vào cách containers được xây dựng, bạn có thể nhận được thông báo rằng không tìm thấy bash . Trong trường hợp này, bạn sẽ phải sử dụng shell sh chung bằng cách thêm nó vào cuối lệnh của bạn:
sudo nsenter -t $PID -m -u -i -n -p /bin/sh Kết luận
Đây chỉ là một vài thủ tục mà bạn có thể sử dụng để khắc phục sự cố với các cụm CoreOS của bạn . Những điều này sẽ giúp bạn theo dõi các vấn đề bạn có thể gặp phải với file cấu hình cloud của bạn và khắc phục sự cố về khả năng phân cụm và khởi động dịch vụ chính xác của máy. Theo dõi các vấn đề với bản thân các containers và dịch vụ Docker là một lĩnh vực khác mà ta đã đề cập.
Một trong những điều quan trọng nhất cần ghi nhớ là việc gỡ lỗi trở nên dễ dàng hơn nhiều khi bạn có nhiều thông tin hơn về hệ thống của bạn . Sẽ rất hữu ích nếu bạn nắm chắc role của từng thành phần và cách chúng tương tác để giúp hệ thống hoạt động. Nếu bạn thấy mình bị lạc khi cố gắng theo dõi một vấn đề, có thể hữu ích nếu bạn tự ôn luyện lại các kiến thức cơ bản về CoreOS.
Các tin liên quan
