Tạp chí Thợ Code

#Nhatkymaymua Chuyện Cloud số này xin giới thiệu cùng quý bạn đọc “Nhật ký thật thụ” của “chiên da” đầu ngành về lĩnh vực Wordpress.

Mấy từ khóa hot hit để quyết định có bỏ một vài trống canh ra đọc chuyện dông dài: Amazon Lightsail, MobaXterm, CloudWatch Agent, Cloudfront.

Số là, có anh chiên da nọ bữa đi uống sinh tố lúa mạch với quản lý một trang web nho nhỏ chạy bằng Wordpress (WP) hiện đang có khoảng 45,000 bài viết và cũng tầm nhiêu đó attachment/ pages với một số custom taxonomy tá lả âm binh các kiểu.

Hiện hệ thống đang gặp tình huống nan giải: thường xuyên hết dung lượng dĩa cứng nên việc hệ thống chậm, hệ thống treo xảy ra như cơm bữa.

Lúc còn ngà ngà sỉn nói chuyện trên bàn nhậu anh chiên da có vẽ sơ bộ một kiến trúc đình đám theo chuẩn Best Practices for WordPress on AWS khiến chủ tịch phải há hốc mồm mà zô chăm phần chăm.

Source: AWS Whitepaper - Best Practices for WordPress on AWS.

Tuy nhiên, sau khi nói chuyện cùng với những người lao động chân chính trực tiếp vận hành và sử dụng hệ thống thì chiên da đã phải…

Vì sao? Vì hệ thống site WP này phục vụ tin tức giới trẻ, gần như cần lên bài xuất bản tin tức liên tục nên việc downtime sẽ là một điểm trừ lớn, cũng như là rất khó ước lượng thời gian để hệ thống hoạt động bình thường vì lượng dữ liệu trên Database và các data file cũng khá nhiều.

Và quan trọng là hệ thống này chỉ có duy nhất một môi trường production nên khó lòng mà liều lĩnh được. Nên chiên da bắt đầu quá trình tìm hiểu hệ thống hiện tại, sau khi xin khắp nơi đầu này đầu kia thì cũng có thông tin để SSH vào server và tuyệt vời hơn nữa là Pé Thư ký chủ tịch còn tìm ra được email chứa thông tin để login vào AWS Console, hệ thống hiện tại khá đơn giản, chỉ duy nhất 1 Intance trên Amazon Lightsail, chủ yếu phức tạp trong việc cài cắm phần mềm bên trong Instance này.

Còn một điều hết sức lạ kỳ nữa: Amazon Lightsail Instance thì nằm trong một Root account A, còn Route53 và S3 Storage thì nằm ở một Root account B khác, thật kỳ lạ. Chắc là có uẩn khúc gì trong này, nhưng thôi xác định điều này không thuộc scope của mình nên chiên da cũng không đào sâu.

Do đó, đầu tiên, sau khi login được vào Amazon Lightsail Console việc cần làm là tạo snapshot để backup toàn bộ hệ thống hiện tại. Theo giá ở https://aws.amazon.com/lightsail/pricing/ thì sẽ tốn $0.05 USD/ tháng bất kể là manual hay automatic snapshot.

Sau khi đã có snapshot thì có thể dễ dàng tạo một instance mới y chang để thử nghiệm hoặc triển khai môi trường dev/ test.

Từ Console Amazon Lightsail chọn Instance cần kết nối, lý tưởng nhất là Instance dev/ test vừa tạo ra từ bản snapshot ở bước trên, chọn Download default key để tải về SSH Key dùng cho việc kết nối vào Instance. Một file key sẽ dùng chung cho các Instance trong toàn bộ region.

Thật ra, bạn vẫn có thể kết nối SSH trực tiếp ngay trên browser bằng tính năng Use your browser, Connect using our browser-based SSH client, Connect using SSH. Nhưng nhìn chung thì có khá nhiều thứ còn bất tiện như việc keep session, download upload file… Do đó, ở đây tôi sẽ sử dụng MobaXterm, đối với dân dùng Windows thì đây là một công cụ rất tuyệt vời, phiên bản miễn phí hỗ trợ tất cả các tính năng cần thiết. Ngoài MobaXterm thì bạn còn có thể lựa chọn Bitvise SSH Client hay PuTTY.

Để sử dụng MobaXterm, bạn điền Remote host (IP), Specify username và chọn Use private key trong mục Advanced SSH settings.

Kết nối thành công, thấy màn hình welcome hiện ra logo Bitnami huyền thoại. Gồi gồi, chơi hàng AIO rồi, cho bạn nào chưa có dịp tìm hiểu thì Bitnami cho WordPress cung cấp giải pháp cài đặt một-click, dễ dàng triển khai WordPress trên máy ảo hoặc máy chủ đám mây. Nó hỗ trợ cấu hình đa tầng để cải thiện khả năng mở rộng, cập nhật bảo mật thường xuyên, và tính nhất quán trên nhiều nền tảng. Bitnami rất phù hợp cho cả cá nhân và doanh nghiệp muốn sử dụng WordPress an toàn và nhanh chóng.

OK, vậy có nghĩa là mọi thứ đều nằm trong Instance này hết rồi, cũng đỡ. Tui chạy lệnh df -h để xem thử có thật là hết ổ cứng không. Đúng là hết thật, full 100%!

Rồi, tiếp tục chạy lệnh du -sh /bitnami/wordpress/wp-content/ để xem thử thư mục wp-content chiếm bao nhiêu dung lượng. Thư mục wp-content trong WordPress chứa tất cả các nội dung tùy chỉnh và tệp tin bổ sung của trang web. Đây là thư mục quan trọng vì nó lưu trữ các dữ liệu và tùy chỉnh riêng biệt mà không ảnh hưởng đến mã nguồn cốt lõi của WordPress

Quả thực thủ phạm đây rồi, nhưng đã có S3 rồi mà sao còn tuầy huầy trong này vậy cà!? Lại tiếp tục chạy lệnh du -h --max-depth=1 /bitnami/wordpress/wp-content/ để xem chi tiết cụ thể từng thư mục con.

Sau khi uống hết hai ba ly cà-phê ngồi đợi thì kết quả như sau, thư mục /cache tạm thời chưa biết do plugins nào tạo ra nhưng quá kinh khủng, còn hơn cả /uploads.

~$ du -h --max-depth=1 /bitnami/wordpress/wp-content/
36K     /bitnami/wordpress/wp-content/w3tc-config
51G     /bitnami/wordpress/wp-content/cache
19G     /bitnami/wordpress/wp-content/uploads
21M     /bitnami/wordpress/wp-content/themes
4.4M    /bitnami/wordpress/wp-content/languages
402M    /bitnami/wordpress/wp-content/plugins
4.0K    /bitnami/wordpress/wp-content/upgrade
71G     /bitnami/wordpress/wp-content/

Tiếp tục chạy lệnh grep -Rnw /bitnami/wordpress/wp-content/plugins/ -e '/cache’ để tìm xem thư mục /cache này được sử dụng bở plugins nào. Ngay từ kết quả đầu tiên như bên dưới có thể thấy được liên quan đến wp-content/plugins/w3-total-cache.

W3 Total Cache (W3TC) cải thiện SEO, Core Web Vitals và trải nghiệm người dùng tổng thể của trang web bằng cách tăng hiệu suất và giảm thời gian tải thông qua việc tích hợp mạng phân phối nội dung (CDN) và các phương pháp tối ưu hóa mới nhất. W3TC là một framework tối ưu hóa hiệu suất web duy nhất không phụ thuộc vào nhà cung cấp dịch vụ lưu trữ, được hàng triệu nhà xuất bản, nhà phát triển web và nhà cung cấp dịch vụ lưu trữ tin tưởng trong hơn một thập kỷ qua. Đây là giải pháp hoàn chỉnh để tối ưu hóa hiệu suất cho các trang web WordPress.

grep -Rnw /bitnami/wordpress/wp-content/plugins/ -e '/cache'
/bitnami/wordpress/wp-content/plugins/w3-total-cache/lib/SNS/sdk.class.php:688:  * @param string $location (Required) <p>The location to store the cache object in. This may vary by cache method.</p><ul><li>File - The local file system paths such as <code>./cache</code> (relative) or <code>/tmp/cache/</code> (absolute). The location must be server-writable.</li><li>APC - Pass in <code>apc</code> to use this lightweight cache. You must have the <a href="http://php.net/apc">APC extension</a> installed.</li><li>XCache - Pass in <code>xcache</code> to use this lightweight cache. You must have the <a href="http://xcache.lighttpd.net">XCache</a> extension installed.</li><li>Memcached - Pass in an indexed array of associative arrays. Each associative array should have a <code>host</code> and a <code>port</code> value representing a <a href="http://php.net/memcached">Memcached</a> server to connect to.</li><li>PDO - A URL-style string (e.g. <code>pdo.mysql://user:pass@localhost/cache</code>) or a standard DSN-style string (e.g. <code>pdo.sqlite:/sqlite/cache.db</code>). MUST be prefixed with <code>pdo.</code>. See <code>CachePDO</code> and <a href="http://php.net/pdo">PDO</a> for more details.</li></ul>
/bitnami/wordpress/wp-content/plugins/w3-total-cache/lib/NetDNA/NetDNA.php:427:                 '/zones/pull.json/' . $zone_id . '/cache',
/bitnami/wordpress/wp-content/plugins/w3-total-cache/vendor/aws/aws-sdk-php/src/data/apigateway/2015-07-09/api-2.json.php:3:return [ 'version' => '2.0', 'metadata' => [ 'apiVersion' => '2015-07-09', 'endpointPrefix' => 'apigateway', 'protocol' => 'rest-json', 'serviceFullName' => 'Amazon API Gateway', 'serviceId' => 'API Gateway', 'signatureVersion' => 'v4', 'uid' => 'apigateway-2015-07-09', ], 'operations' => [ 'CreateApiKey' => [ 'name' => 'CreateApiKey', 'http' => [ 'method' => 'POST', 'requestUri' => '/apikeys', 'responseCode' => 201, ], 'input' => [ 'shape' => 'CreateApiKeyRequest', ], 'output' => [ 'shape' => 'ApiKey', ], 'errors' => [ [ 'shape' => 'UnauthorizedException', ], [ 'shape' => 'NotFoundException', ], [ 'shape' => 'TooManyRequestsException', ], [ 'shape' => 

OK, ta đăng nhập vào WP và tắt plugin này thôi. Nhưng làm sao để lấy thông tin account admin của WP, chưa chắc Pé Thư Ký chủ tịch đã biết, may mắn là hệ thống này sử dụng Bitnami nên tui dễ dàng chạy lệnh sudo cat /home/bitnami/bitnami_credentials để lấy thông tin account admin.

Vào menu Plugins> W3 Total Cache> Deactivate. Sau đó thì Delete luôn, giải phóng hơn 50% dung lượng dĩa cứng bị chiếm dụng.

Quay lại SSH terminal, ta chạy lệnh sudo rm -rf /bitnami/wordpress/wp-content/cache/ để xóa hết các tàn tích tồn đọng, nhớ phải snapshot hay backup nghen. Chạy lại lệnh df -h, ngon lành!

df -h
Filesystem       Size  Used Avail Use% Mounted on
udev             1.9G     0  1.9G   0% /dev
tmpfs            388M  424K  387M   1% /run
/dev/nvme0n1p1    79G   43G   33G  57% /
tmpfs            1.9G     0  1.9G   0% /dev/shm
tmpfs            5.0M     0  5.0M   0% /run/lock
/dev/nvme0n1p15  124M   11M  114M   9% /boot/efi
tmpfs            388M     0  388M   0% /run/user/1000

Xóa xong rồi thì giờ sao?

• Cài đặt các alarm trên Instance hiện tại để thông báo cho quản trị hệ thống.
• Thay thế plugin cache W3 Total Cache trên WP bằng Cloudfront.

Đáng tiếc là các metric sẵn có không hỗ trợ theo dõi dung lượng dĩa cứng, và những metric sẵn có cũng có một số metric không hỗ trợ alarm. Do đó chúng ta sẽ tự cài đặt thêm CloudWatch Agent trên Instance này.

Amazon CloudWatch thu thập dữ liệu giám sát và vận hành dưới dạng nhật ký, số liệu và sự kiện. Dịch vụ cung cấp một cái nhìn hợp nhất về các tài nguyên AWS, ứng dụng và dịch vụ chạy trên AWS cũng như các máy chủ tại chỗ. Bạn có thể cấu hình tài nguyên Lightsail của mình để làm việc với Amazon CloudWatch và nhận được nhiều số liệu hơn.

Các phần sau đây bao gồm các bước để cài đặt tác nhân CloudWatch trên instance Amazon Lightsail của bạn và cấu hình nó với quyền cần thiết để gửi các số liệu về mức sử dụng memory hay disk đến Amazon CloudWatch.

Theo Amazon Q thì bạn có thể sử dụng free tier Amazon CloudWatch bao gồm 1 triệu yêu cầu API, 5 GB dữ liệu log và 10 metric tùy chỉnh mỗi tháng, đủ để giám sát instance Lightsail của bạn. Tuy nhiên, hãy lưu ý rằng gói free tier không bao gồm chi phí xử lý dữ liệu, với mức phí là $0.10 cho mỗi GB dữ liệu được xử lý. Thông tin thêm: https://aws.amazon.com/cloudwatch/pricing/

IAM User này sẽ cho phép Instance có quyền gửi dữ liệu đến CloudWatch service.

• Vào AWS Management Console> IAM. Chọn Users> Add user.
• Nhập User name vào textbox rồi bấm Next.
• Trong Permissions options chọn Attach existing policies directly. Nhập CloudWatchAgentServerPolicy vào ô tìm kiếm rồi chọn policy này.

• Bấm Next, bấm Create user để tạo IAM User.
• Sau khi tạo thành công IAM User, chọn User vừa tạo để lấy Access key và Secret key: chọn tab Security credentials, kéo xuống phần Access keys, bấm nút Create access key.
• Chọn Application running on an AWS compute service trong phần Access key best practices & alternatives, tiếp tục check vào Confirmation rồi bấm Next. Bấm nút Create access key.
• Bạn nhớ lưu trữ an toàn và cẩn thận key này, thông tin chỉ hiển thị một lần, mất thì phải tạo lại, lọt lộ thì ảnh hưởng đến tính an toàn của hệ thống.

• SSH vào Instance
• Vì hệ thống dùng Debian nên chúng ta chạy lệnh bên dưới để tải về gói cài đặt amazon-cloudwatch-agent.

wget https://amazoncloudwatch-agent.s3.amazonaws.com/debian/amd64/latest/amazon-cloudwatch-agent.deb

Làm sao biết hệ thống dùng OS nào?

$ uname -a
Linux ip-xxx-xxx-xxx-xxx 5.10.0-30-cloud-amd64 #1 SMP Debian 5.10.218-1 (2024-06-01) x86_64 GNU/Linux

• Cài đặt gói vừa tải về

sudo dpkg -i -E ./amazon-cloudwatch-agent.deb

Selecting previously unselected package amazon-cloudwatch-agent.
(Reading database ... 38624 files and directories currently installed.)
Preparing to unpack ./amazon-cloudwatch-agent.deb ...
create group cwagent, result: 0
create user cwagent, result: 0
Unpacking amazon-cloudwatch-agent (1.300048.1b904-1) ...
Setting up amazon-cloudwatch-agent (1.300048.1b904-1) ...

• Chạy lệnh bên dưới để cấu hình profile AWS CLI trên Instance sử dụng thông tin IAM account vừa tạo ở bước trên. Lệnh này cho phép bạn thiết lập các thông tin xác thực và cấu hình mặc định để làm việc với các dịch vụ AWS từ dòng lệnh.

sudo aws configure --profile AmazonCloudWatchAgent

Nhập các thông tin:

AWS Access Key ID [None]: <thông tin đã lưu ở bước trên>
AWS Secret Access Key [None]: <thông tin đã lưu ở bước trên>
Default region name [None]:
Default output format [None]:

Các thông tin này sẽ được lưu trữ trong các tệp cấu hình tại ~/.aws/credentials và ~/.aws/config, giúp AWS CLI biết các cài đặt mặc định khi thực hiện các lệnh. Bạn có thể chỉnh sửa trực tiếp các tệp này hoặc chạy lại aws configure để thay đổi thông tin.

Sau khi cài xong agent thì chúng ta cần phải chỉ cho CloudWatch Agent nên thu thập những thông số nào của hệ thống.

Chạy lệnh bên dưới để tạo file cấu hình cho CloudWatch Agent. Nếu không thích nano, bạn có thể dùng vim cũng không sao.

sudo nano /opt/aws/amazon-cloudwatch-agent/bin/config.json

Dán đoạn cấu hình như bên dưới vào nano editor. Bấm Ctrl/ Command + X nhập Y và Enter 2 lần để lưu lại thông tin.

{
    "agent": {
        "metrics_collection_interval": 60,
        "run_as_user": "root"
    },
    "metrics": {
        "append_dimensions": {
            "ImageID": "${aws:ImageId}",
            "InstanceId":"${aws:InstanceId}",
            "InstanceType":"${aws:InstanceType}"
        },
        "metrics_collected": {
            "mem": {
                "measurement": [
                    "mem_used_percent"
                ],
                "metrics_collection_interval": 60
            },
            "disk": {
                "measurement": [
                    "used_percent"
                ],
                "metrics_collection_interval": 60,
                "resources": [
                    "/"
                ]
            }
        }
    }
}

Trong đó:

• "metrics_collection_interval": 60: Xác định khoảng thời gian giữa mỗi lần thu thập số liệu, ở đây là 60 giây. Điều này có nghĩa là cứ mỗi phút, CloudWatch Agent sẽ thu thập và gửi các số liệu đến Amazon CloudWatch.
• "run_as_user": "root": Xác định người dùng mà CloudWatch Agent sẽ chạy dưới quyền. Trong trường hợp này, agent sẽ chạy với quyền root, cho phép nó truy cập tất cả các tài nguyên hệ thống.
• "append_dimensions": Phần này thêm các thông tin metadata bổ sung cho các số liệu để xác định chính xác nguồn gốc dữ liệu.
• "metrics_collected": Phần này xác định các loại số liệu nào sẽ được thu thập (ví dụ: memory và disk) và các thông tin cụ thể về cách chúng được thu thập.
• "measurement": ["mem_used_percent"]: Xác định loại số liệu cần thu thập từ bộ nhớ. Ở đây, mem_used_percent là phần trăm bộ nhớ đã được sử dụng.
• "metrics_collection_interval": 60: Chỉ ra rằng số liệu này sẽ được thu thập mỗi 60 giây (1 phút).
• "measurement": ["used_percent"]: Xác định loại số liệu liên quan đến dung lượng đĩa cần thu thập. Ở đây, used_percent là phần trăm dung lượng đĩa đã sử dụng trên các điểm mount chỉ định.
• "metrics_collection_interval": 60: Khoảng thời gian thu thập số liệu về dung lượng đĩa, mỗi 60 giây (1 phút).
• "resources": ["/"]: Xác định các điểm mount cụ thể trên hệ thống mà CloudWatch Agent sẽ giám sát. Ở đây, "/" là điểm mount root (thư mục gốc). Bạn có thể thêm nhiều điểm mount khác nếu cần (ví dụ: "/data", "/home").

Chúng ta sẽ cấu hình để CloudWatch Agent sử dụng profile AWS CLI đã tạo trước đó.

Chạy lệnh sau để tạo file cấu hình chung cho CloudWatch Agent.

sudo nano /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml

Chèn thêm đoạn cấu hình bên dưới vào file common-config.toml đã sẵn có.

[credentials]
shared_credential_profile = "AmazonCloudWatchAgent"

$ sudo amazon-cloudwatch-agent-ctl -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json -a fetch-config -s

****** processing amazon-cloudwatch-agent ******
Got Home directory: /root I! Set home dir Linux: /root I! SDKRegionWithCredsMap region: I! Trying to detect region from ec2 D! [EC2] Found active network interface I! imds retry client will retry 1 timesSuccessfully fetched the config and saved in /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/file_config.json.tmp
Start configuration validation...
2024/10/29 08:30:35 Reading json config file path: /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/file_config.json.tmp ...
2024/10/29 08:30:35 I! Valid Json input schema.
2024/10/29 08:30:35 D! ec2tagger processor required because append_dimensions is set
2024/10/29 08:30:35 Configuration validation first phase succeeded
I! Detecting run_as_user...
Got Home directory: /root
Got Home directory: /root
I! Set home dir Linux: /root
I! SDKRegionWithCredsMap region:
I! Trying to detect region from ec2
D! [EC2] Found active network interface
I! imds retry client will retry 1 times
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent -schematest -config /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml
Configuration validation second phase succeeded
Configuration validation succeeded

Kiểm tra trạng thái của CloudWatch Agent vừa khởi động

$ sudo amazon-cloudwatch-agent-ctl -a status

{
  "status": "running",
  "starttime": "2024-12-29T08:30:34+00:00",
  "configstatus": "configured",
  "version": "1.300048.1b904"
}

Đến đây xem như đã hoàn thành cơ bản việc cài đặt cảnh báo trên Instance Amazon Lightsail.

Quay lại AWS Management Console> CloudWatch> Metrics> All metrics, trong phần Custom namespaces bạn sẽ nhìn thấy CWAgent như hình minh họa.

Chọn InstanceId, InstanceType, device, fstype, path là những metric vừa cấu hình trong file config.json ở trên.

Chuyện bây giờ đã dễ dàng rất nhiều vì CloudWatch hỗ trợ sẵn tính năng này rất mạnh mẽ.

Trong phần Metrics, bạn bấm nút Create alarm.

Thông tin về metric sẽ được tự động điền, chúng ta chỉ cần quan tâm mục Conditions> Whenever disk_used_percent is... để thiết lập giá trị cảnh báo.

Vì để kiểm tra nên tôi tạm thiết lập là 30% như hình minh họa. Trong thực tế, theo Gen AI khuyên thì trên môi trường Production: Ngưỡng 80% là lựa chọn phổ biến để đảm bảo không có gián đoạn khi dung lượng đĩa sắp đầy. Còn trên môi trường Development/Test: Bạn có thể đặt ngưỡng cao hơn (90%-95%) nếu hệ thống không yêu cầu ổn định cao.

Bấm Next.

Ngoài ra, cũng trong màn hình Specify metric and conditions bên trên bạn có thể cấu hình thêm Datapoints to alarm trong Additional configuration để hạn chế các cảnh báo giả. Đây là nơi điều chỉnh độ nhạy của alarm, vì trong thực tế có những trường hợp hệ thống chạy một số tác vụ nào đó sinh ra temporary file trong thời gian ngắn dẫn đến chỉ số chạm ngưỡng.

Nếu bạn đặt 1 out of 1, điều này có nghĩa là chỉ cần 1 điểm dữ liệu vi phạm ngưỡng trong khoảng thời gian đánh giá là đủ để kích hoạt báo động. Nếu bạn muốn chắc chắn hơn, bạn có thể đặt thành 2 out of 3 chẳng hạn, nghĩa là cần 2 trong số 3 điểm dữ liệu vi phạm liên tiếp để đưa báo động vào trạng thái ALARM. Điều này giúp tránh cảnh báo sai nếu có sự dao động nhỏ trong các chỉ số.

• Treat missing data as missing: Xem dữ liệu thiếu là không có và không đánh giá chúng. Điều này phù hợp khi dữ liệu có thể không được ghi nhận liên tục và bạn không muốn CloudWatch báo động do thiếu dữ liệu.
• Treat missing data as breaching: Xem dữ liệu thiếu như một điểm vi phạm ngưỡng. Tùy chọn này sẽ làm báo động nhạy cảm hơn và có thể kích hoạt nếu dữ liệu bị thiếu.
• Treat missing data as not breaching: Xem dữ liệu thiếu như không vi phạm ngưỡng, giúp tránh các báo động sai khi thiếu dữ liệu.
• Ignore missing data: Bỏ qua dữ liệu bị thiếu và đánh giá dựa trên các điểm dữ liệu hiện có. Đây là lựa chọn mặc định nếu bạn không có yêu cầu đặc biệt.

Bạn có thể chỉ định các hành động mà cảnh báo thực hiện khi nó thay đổi trạng thái giữa các trạng thái OK, ALARM và INSUFFICIENT_DATA.

Chọn In alarm trong phần Alarm state trigger, tiếp đến chọn Create new topic rồi nhập thông tin tên topic Amazon Simple Notification Service (SNS), nhập email muốn nhận thông báo vào textbox Email endpoints that will receive the notification. Bấm nút Create topic để hoàn tất.

Bạn có thể thêm nhiều hành độg cảnh báo khác nhau bằng cách bấm nút Add notification để tiếp tục lặp lại quá trình cấu hình với các tùy chọn khác nhau, chẳng hạn khi disk usage giảm xuống ngưỡng cho phép thì tiếp tục gửi một email thông báo với nội dung khác chẳng hạn.

Sau khi xong các cấu hình, bạn bấm nút Next để sang bước tiếp theo.

Nhập tên alarm, cũng như là custom message gửi đến email nếu cần thiết, bạn có thể sử dụng markdown format để soạn custom message này. Bấm nút Next. Sau đó bấm nút Create alarm để hoàn tất.

Một email với tiêu đề AWS Notification - Subscription Confirmation sẽ được gửi đến địa chỉ email mà bạn vừa nhập ở trên, hãy đảm bảo click vào link Confirm subscription trong email.

Thấy vầy là ngon lành

Hiện tại tui chưa tìm thấy cách nào để có thể tạo Cloudfront distribution trực tiếp trỏ thẳng vào Amazon Lightsail, nên chúng ta sẽ sử dụng phương pháp như sau…

Chuyện thế nào xin mời quý đọc giải đón xem phần tiếp theo của Bán nguyệt san #Nhatkymaymua.

Biên soạn: Tí Dev. Hiệu đính & bắt lỗi chính tả: Anh Dũng.

Cover by: WordPress wallpapers.

Sài Gòn, thế kỷ hăm mốt.