有多少人曾為應(yīng)用程序數(shù)據(jù)庫(kù)的擴(kuò)展和優(yōu)化而頭疼？如果你還沒(méi)有閱讀過(guò)《如何用 Django 搞定 SQL 的 “臟活累活”》，強(qiáng)烈建議先看看那篇文章。簡(jiǎn)單來(lái)說(shuō)，SQL 是專(zhuān)為 SQL 數(shù)據(jù)庫(kù)優(yōu)化的，Python 則不是，而 Django 可以充當(dāng)一個(gè)中介，幫助我們構(gòu)建更有效的應(yīng)用程序，同時(shí)在配合使用這兩種語(yǔ)言時(shí)減少摩擦，降低復(fù)雜性和代碼量。

然而，盡管 Django 承擔(dān)了創(chuàng)建數(shù)據(jù)庫(kù)應(yīng)用的重任，我們依然需要承擔(dān)數(shù)據(jù)庫(kù)的日常管理和監(jiān)控工作。好在只要使用諸如 Linode Managed Databases 這樣的托管數(shù)據(jù)庫(kù)服務(wù)，很多管理任務(wù)都可以委托給云提供商，但我們可能依然會(huì)在應(yīng)用擴(kuò)展的過(guò)程中遇到新問(wèn)題，例如：

• 數(shù)據(jù)庫(kù)遷移。將現(xiàn)有數(shù)據(jù)庫(kù)切換為新的所需狀態(tài)，并以可控的方式更改數(shù)據(jù)庫(kù) Schema。
• 多數(shù)據(jù)庫(kù)部署。為了優(yōu)化性能，開(kāi)發(fā)者可以設(shè)計(jì)應(yīng)用程序中的不同功能使用獨(dú)立的數(shù)據(jù)庫(kù)。例如，一個(gè)主要的讀 / 寫(xiě)數(shù)據(jù)庫(kù)和一個(gè)為通用查詢(xún)提供服務(wù)的可讀副本數(shù)據(jù)庫(kù)。

如果其中一個(gè)數(shù)據(jù)庫(kù)使用了 SQL，我們可以按照《如何用 Django 搞定 SQL 的 “臟活累活”》一文的介紹，大幅簡(jiǎn)化海量數(shù)據(jù)的處理工作。

本文將介紹數(shù)據(jù)庫(kù)管理工作中的兩個(gè)重要概念，并通過(guò)循序漸進(jìn)的指南告訴大家該如何構(gòu)建面向生產(chǎn)環(huán)境的 Django 應(yīng)用程序。

延伸閱讀，了解Akamai cloud-computing

出海云服務(wù)，選擇Akamai Linode！

數(shù)據(jù)庫(kù)遷移

在剛上手時(shí)，為數(shù)據(jù)庫(kù)中不同列的內(nèi)容確定適合的數(shù)據(jù)類(lèi)型，這可能是個(gè)有點(diǎn)棘手的任務(wù)，如果有關(guān)數(shù)據(jù)的需求會(huì)隨著時(shí)間推移不可避免產(chǎn)生變化，感覺(jué)就更棘手了。如果希望標(biāo)題字段只能包含 80 個(gè)字符該怎么辦？如果需要添加一個(gè)時(shí)間戳字段以便準(zhǔn)確追蹤每個(gè)內(nèi)容是在什么時(shí)候加入數(shù)據(jù)庫(kù)的又該怎么辦？

在創(chuàng)建好一個(gè)表之后再更改其內(nèi)容，可能會(huì)產(chǎn)生一些非?；靵y的后果，原因主要在于：

• 該如何處理已經(jīng)存在的值？
• 如果原有的行缺少新增列 / 字段對(duì)應(yīng)的數(shù)據(jù)該怎么辦？
• 如果刪除了某個(gè)列 / 字段該怎么辦？數(shù)據(jù)會(huì)發(fā)生什么變化？
• 如果添加了一個(gè)之前不存在的關(guān)系（例如外鍵）又該如何處理？

好在對(duì)于 Django 開(kāi)發(fā)者來(lái)說(shuō)，可以使用 makemigrations 和 migrate。一起看看它們是如何生效的。

以如下的 Django 數(shù)據(jù)模型為例：

class BlogArticle(models.Model):
 user = models.ForeignKey(User, default=1, on_delete=models.SET_DEFAULT)
 title = models.CharField(max_length=120)
 slug = models.SlugField(blank=True, null=True)
 content = models.TextField(blank=True, null=True)
 publish_timestamp = models.DateTimeField(
 auto_now_add=False,
 auto_now=False,
 blank=True,
 null=True,
 )

先來(lái)添加一個(gè)字段：

updated_by = models.ForeignKey(
 User, related_name="editor", null=True, blank=True, on_delete=models.SET_NULL
)

該字段可供我們追蹤修改了模型的最后一個(gè)用戶(hù)。

接著更新一下這個(gè)模型：

class BlogArticle(models.Model):
 user = models.ForeignKey(User, default=1, on_delete=models.SET_DEFAULT)
 title = models.CharField(max_length=120)
 slug = models.SlugField(blank=True, null=True)
 content = models.TextField(blank=True, null=True)
 publish_timestamp = models.DateTimeField(
 auto_now_add=False,
 auto_now=False,
 blank=True,
 null=True,
 )
 # our new field
 updated_by = models.ForeignKey(
 User, related_name="editor", null=True, blank=True, on_delete=models.SET_NULL
 )

當(dāng)我們保存了 BlogArticle 類(lèi)所聲明的文件（models.py）后，如何讓數(shù)據(jù)庫(kù)知道發(fā)生了這個(gè)改動(dòng)？有兩種方法：

• python manage.py makemigrations
• python manage.py migrate

一起看看這兩個(gè)命令的作用吧。

1.python manage.py makemigrations

python manage.py makemigrations 可以在我們的 Django 項(xiàng)目中尋找對(duì) models.py 文件進(jìn)行的所有改動(dòng)。如果找到改動(dòng)，將創(chuàng)建一個(gè)全新的 Python 文件，其中包含 SQL 數(shù)據(jù)庫(kù)需要進(jìn)行的提議變更（Proposed change）。這種提議變更看起來(lái)類(lèi)似這樣：

from django.conf import settings
from django.db import migrations, models
import django.db.models.deletion
class Migration(migrations.Migration):
 dependencies = [
 migrations.swappable_dependency(settings.AUTH_USER_MODEL),
 ('articles', '0001_initial'),
 ]
 operations = [
 migrations.AddField(
 model_name='article',
 name='updated_by',
 field=models.ForeignKey(blank=True, null=True, on_delete=django.db.models.deletion.SET_NULL, related_name='editor', to=settings.AUTH_USER_MODEL),
 ),
 ]

這當(dāng)然也是另一個(gè) Python 文件。開(kāi)發(fā)者可以通過(guò)該文件了解數(shù)據(jù)庫(kù)中應(yīng)該發(fā)生的事情。為了維持一致并利用 Django ORM 的內(nèi)置功能，該文件會(huì)使用 Python 編寫(xiě)（而非 SQL）。

但為什么這個(gè)文件中記錄了應(yīng)該發(fā)生的事情？主要原因在于：

• 如果我們希望在實(shí)際發(fā)生前檢查應(yīng)該發(fā)生的事情，可以直接通過(guò)該文件了解。
• Makemigrations 命令并不會(huì)通過(guò)檢查數(shù)據(jù)庫(kù)來(lái)判斷這些變化是否可以真正發(fā)生。
• 為了使用這些要求，數(shù)據(jù)庫(kù)可能已經(jīng)發(fā)生了改變（取決于誰(shuí)在管理數(shù)據(jù)庫(kù)等一系列因素）。
• 如果希望在更改生產(chǎn)數(shù)據(jù)庫(kù)前進(jìn)行測(cè)試，那么此時(shí)就是最佳時(shí)機(jī)。

假設(shè)這些變更是有效的（只要我們可以正確判斷），隨后就可以通過(guò)下列方法提交這些變更了。

2.python manage.py migrate

python manage.py migrate 將嘗試著為我們更改數(shù)據(jù)庫(kù)（所有字段、列、表、外鍵等），Django 會(huì)代替我們做這些工作，以確保數(shù)據(jù)庫(kù)能按照我們希望的方式更新。

需要注意的是，Django 可能會(huì)因?yàn)橐恍┰蚨?/span>無(wú)法執(zhí)行這些變更。對(duì)于新接觸 Django 的開(kāi)發(fā)者，最主要的原因往往是添加或刪除了字段 / 列，但未能正確進(jìn)行遷移。

如果操作正確無(wú)誤，python manage.py migrate 可以保證產(chǎn)生穩(wěn)定的系統(tǒng)，并且各方面均與我們的 Python 代碼和 SQL 表保持匹配，從而確?？梢哉_發(fā)揮出 Django 和 SQL 數(shù)據(jù)庫(kù)提供的強(qiáng)大功能。

這種做法如何為我們帶來(lái)更高靈活性？

Python 有著廣泛的應(yīng)用，但 SQL 就未必了。顧名思義，結(jié)構(gòu)化查詢(xún)語(yǔ)言（Structured Query Language）存在一些固有的局限。誰(shuí)能只使用 SQL 就創(chuàng)建出精彩的動(dòng)畫(huà)電影呢？

這樣說(shuō)的意圖在于，Python 的簡(jiǎn)潔性有助于開(kāi)發(fā)者發(fā)揮出 SQL 的真正威力，甚至可能是在不知不覺(jué)中發(fā)揮出來(lái)的。

為何使用托管數(shù)據(jù)庫(kù)和 Django 是合理的做法

在創(chuàng)建包括 Django 在內(nèi)的 Web 應(yīng)用程序時(shí)，我們需要決定一些事情，例如：

1. 需要怎樣的一種或多種數(shù)據(jù)存儲(chǔ)解決方案？MySQL、Postgres、MongoDB、Redis、Object Storage……
2. 如何運(yùn)行以及與數(shù)據(jù)存儲(chǔ)解決方案進(jìn)行集成？
3. 如何從中斷或停機(jī)中恢復(fù)？
4. 如何維護(hù)存儲(chǔ)解決方案？
5. 如何保護(hù)存儲(chǔ)解決方案？
6. 如何備份存儲(chǔ)解決方案？

上述這些問(wèn)題的答案可能會(huì)隨著項(xiàng)目復(fù)雜性的提高而改變，但所有答案都始于同一個(gè)地方：決定到底是使用自管理的還是第三方托管的存儲(chǔ)解決方案。

自管理數(shù)據(jù)庫(kù)：

• 優(yōu)勢(shì)：控制能力和更低的成本
• （巨大的）不足：一切都由我們自行負(fù)責(zé)

托管服務(wù)往往從一開(kāi)始就需要付出更多成本，而自行管理意味著我們可以使用自己喜歡，并且以某種方式（或在某種程度上）針對(duì)我們的需求進(jìn)行了優(yōu)化的 Linux 發(fā)行版。例如我們可以用自己團(tuán)隊(duì)創(chuàng)建并修改的 MySQL 分支版本。自行運(yùn)行的服務(wù)往往更省錢(qián)，但需要付出更多的時(shí)間和精力來(lái)維護(hù)。

第三方托管數(shù)據(jù)庫(kù)服務(wù)：

沒(méi)錯(cuò)，這類(lèi)服務(wù)往往成本更高一些，但可以大幅減少我們需要投入的維護(hù)時(shí)間。這種方式以及托管式的數(shù)據(jù)存儲(chǔ)解決方案已經(jīng)成為很多 Web 應(yīng)用程序的首選。本例中，我們已經(jīng)在使用 Django 來(lái)管理數(shù)據(jù)庫(kù)事務(wù)，SQLAlchemy 也具備類(lèi)似優(yōu)勢(shì)，因?yàn)樗梢耘浜?FastAPI、Flask 等框架一起使用。如果你已經(jīng)將 SQL 的相關(guān)開(kāi)發(fā)工作通過(guò) Python 包來(lái)實(shí)現(xiàn)，那么為何不把 SQL 服務(wù)器的運(yùn)行也照此處理？

考慮到 Python ORM（例如 Django ORM 和 SQLAlchemy）的效果，建議盡可能使用托管數(shù)據(jù)庫(kù)和 / 或托管的數(shù)據(jù)存儲(chǔ)服務(wù)，從而可以獲得下列這些收益：

• 縮短開(kāi)發(fā)時(shí)間
• 縮短管理時(shí)間
• 縮短恢復(fù)時(shí)間
• 減少服務(wù)中斷
• 降低部署和開(kāi)發(fā)工作的復(fù)雜度
• 減少（從其他服務(wù)）遷移數(shù)據(jù)庫(kù)的復(fù)雜度
• 減少 SQL 開(kāi)發(fā)者的重復(fù) / 無(wú)效 / 低效活動(dòng)
• 降低 DevOps/Ops 復(fù)雜度
• 提高 non-SQL 開(kāi)發(fā)者的效率
• 加快部署和開(kāi)發(fā)速度
• 提高可靠性（托管服務(wù)通常有服務(wù)級(jí)別協(xié)議作為保證）
• 增強(qiáng)安全性
• 增強(qiáng)可維護(hù)性
• 增加備份和冗余
• 成本略微增加

實(shí)現(xiàn)上述好處的前提是：在 Linode 平臺(tái)上使用托管的 MySQL 數(shù)據(jù)庫(kù)集群，并使用 Linode 的 Object Storage（存儲(chǔ) CSS、JavaScript、圖像、視頻等文件）。實(shí)際上，使用這些服務(wù)還有助于我們將更多精力專(zhuān)注于通過(guò) Django、 FastAPI、Flask、Node.js 等技術(shù)構(gòu)建卓越的 Web 應(yīng)用程序。換句話(huà)說(shuō)，我們可以將工作的重心放在構(gòu)建用戶(hù)實(shí)際需要的工具和軟件上，畢竟對(duì)用戶(hù)而言，這些才是真正的價(jià)值所在。

MySQL、PostgreSQL、Redis 和 Django

很長(zhǎng)一段時(shí)間以來(lái)，配合 Django 使用最廣泛的數(shù)據(jù)庫(kù)都是 PostgreSQL，這在很大程度上可能因?yàn)橹荒茉?Postgres 中使用 JSONField。然而隨著 Django 3.2 + 和 MySQL 5.7.8 + 的推出，JSONField 也已經(jīng)可用于 MySQL 了。

這一點(diǎn)為何重要？

在處理用戶(hù)生成的內(nèi)容或存儲(chǔ)來(lái)自其他 API 服務(wù)的數(shù)據(jù)時(shí)，通常需要存儲(chǔ)非結(jié)構(gòu)化的數(shù)據(jù)，例如 JSON。一起來(lái)看看具體是怎么做的：

from django.db import models
class Pet(models.Model):
 name = models.CharField(max_length=200)
 data = models.JSONField(null=True)
 def __str__(self):
 return self.name

我們可能想要存儲(chǔ)與“Pet” 有關(guān)的如下數(shù)據(jù)：

pet1 = {
 "name": "Bruno",
 "type": "Rat",
 "nickname": "We don't talk about it",
 "age": 2,
 "age_interval": "months"
}
pet2 = {
 "name": "Tom",
 "type": "Cat",
 "breed": "Mixed"
 "age": 4,
 "age_interval: "years",
 "favorite_food": [{"brand": "Acme", "flavor": "Tuna" }]
}
pet3 = {
 "name": "Stewey",
 "type": "Dog",
 "breed": "unknown"
 "age": 34,
 "age_interval: "dog years",
 "nickname": "Football"
}

從上述數(shù)據(jù)中我們可以知道什么時(shí)候可能需要一個(gè) JSONField。我們可以存儲(chǔ)所有寵物的名字（使用 name 鍵）并將其他信息存儲(chǔ)在 JSONField 中。JSONField 最酷的地方在于，可以像其他標(biāo)準(zhǔn) Django 字段那樣查詢(xún)，哪怕它們使用了不同的 Schema。

Django 開(kāi)發(fā)者之間一直在爭(zhēng)論要使用哪種數(shù)據(jù)庫(kù)：MySQL 或是 PostgreSQL。以前，很多人會(huì)堅(jiān)持選擇 PostgreSQL，因?yàn)?JSONField 只能在 PostgreSQL 中使用，但現(xiàn)在情況不同了。因此我們完全可以任選一個(gè)并一直使用，直到所選數(shù)據(jù)庫(kù)已經(jīng)無(wú)法滿(mǎn)足自己的需求。

但為何又要使用 Redis？

Redis 是一種速度驚人的內(nèi)存中數(shù)據(jù)存儲(chǔ)技術(shù)，因此通常被用作臨時(shí)數(shù)據(jù)庫(kù)（稍后將詳細(xì)介紹這一點(diǎn)）、緩存服務(wù)以及 / 或消息隊(duì)列。之所以將其稱(chēng)之為 “臨時(shí)數(shù)據(jù)庫(kù)” 是因?yàn)樵摷夹g(shù)將數(shù)據(jù)保存在內(nèi)存中，內(nèi)存通常比磁盤(pán)存儲(chǔ)更貴，因此將數(shù)據(jù)長(zhǎng)期存儲(chǔ)在內(nèi)存中往往并不是可行的做法。

本例中的 Redis 和 Django 主要用于緩存和隊(duì)列。

緩存：假設(shè)用戶(hù)需要頻繁訪(fǎng)問(wèn)某幾個(gè)網(wǎng)頁(yè)，我們希望能盡可能快速地向用戶(hù)展示這些頁(yè)面的數(shù)據(jù)。如果配合 Django 使用 Redis 作為緩存系統(tǒng)，就可以輕松實(shí)現(xiàn)這一點(diǎn)。這些頁(yè)面上的數(shù)據(jù)可能是從一個(gè) SQL 數(shù)據(jù)庫(kù)中渲染出來(lái)的，但 Redis 依然可以將渲染出的數(shù)據(jù)存儲(chǔ)在緩存中。換句話(huà)說(shuō)，將 Redis 與 SQL 配合使用通?？梢约涌祉憫?yīng)速度，同時(shí)減少對(duì) SQL 數(shù)據(jù)庫(kù)發(fā)出的查詢(xún)數(shù)量。

隊(duì)列：Redis 的另一個(gè)流行用例是將長(zhǎng)時(shí)間運(yùn)行的任務(wù)分載（Offload）到另一個(gè)進(jìn)程（這通常可借助一個(gè)名為 Celery 的 Python 包實(shí)現(xiàn)）。如果需要這樣做，即可使用 Redis 作為隊(duì)列，保存需要在另一個(gè)時(shí)間完成的任務(wù)。

舉例來(lái)說(shuō)，如果有用戶(hù)需要一份有關(guān)過(guò)去五年來(lái)所有交易的報(bào)表，軟件可能需要花費(fèi)幾小時(shí)才能生成這樣的報(bào)表。很明顯，沒(méi)人愿意盯著計(jì)算機(jī)等待數(shù)小時(shí)之久。因此我們可以把這種請(qǐng)求從用戶(hù)那里分載到一個(gè) Redis 隊(duì)列中。一旦放入 Redis，就可以運(yùn)行工作進(jìn)程（例如將 Celery 與 Django 配合使用）來(lái)生成報(bào)表。報(bào)表創(chuàng)建完成后，無(wú)論該過(guò)程花費(fèi)了多長(zhǎng)時(shí)間，用戶(hù)都能收到通知。和其他通知一樣，這種通知也可以通過(guò) Redis 隊(duì)列與 Celery/Django 工作進(jìn)程配合實(shí)現(xiàn)。

上述內(nèi)容都是為了說(shuō)明：Redis 和 MySQL 可以實(shí)現(xiàn)非常美妙的互補(bǔ)。我們可以通過(guò) Linode Marketplace 部署自行管理的 Redis 數(shù)據(jù)庫(kù)服務(wù)器。

對(duì)象存儲(chǔ)

我們推薦的最后一個(gè)與數(shù)據(jù)有關(guān)的托管服務(wù)是 Linode Object Storage。Object Storage 負(fù)責(zé)保存我們需要存儲(chǔ)的所有其他類(lèi)型的數(shù)據(jù)，畢竟肯定沒(méi)人會(huì)希望將一個(gè)視頻文件的所有數(shù)據(jù)都存儲(chǔ)在 MySQL 中。數(shù)據(jù)庫(kù)可以只用來(lái)存儲(chǔ)與視頻有關(guān)的元數(shù)據(jù)，而視頻文件本身，可以存儲(chǔ)在 Object Storage 中。

我們可以使用對(duì)象存儲(chǔ)服務(wù)來(lái)存儲(chǔ)類(lèi)似下面這些數(shù)據(jù)：

• 層疊樣式表（CSS）
• JavaScript（例如 React.js、Vue.js、Vanilla.js 等）
• 視頻
• 圖像（原始圖像和壓縮后的圖像）
• CSV、XLSX
• 數(shù)據(jù)庫(kù)備份
• Docker 容器鏡像層（如果自行管理）
• 訓(xùn)練后的機(jī)器學(xué)習(xí)算法和后續(xù)迭代
• Terraform State File
• PDF（無(wú)論大?。?/span>
• 任何需要頻繁下載（或上傳）的演示文稿

總結(jié)

按照本文推薦的思路，任何開(kāi)發(fā)者都可以在自己的 Web 應(yīng)用程序項(xiàng)目中充分發(fā)揮托管服務(wù)的力量。Django 是一種在 SQL 數(shù)據(jù)庫(kù)基礎(chǔ)上構(gòu)建 Web 應(yīng)用的出色解決方案，但它并非唯一。如果希望深入探尋 SQL 和 SQL 服務(wù)器的內(nèi)部原理，我們認(rèn)為有必要通過(guò)不斷的研究來(lái)了解到底有多少成功的應(yīng)用程序在使用 Django 來(lái)處理各種工作。

將 Django 與 Linode 的托管 MySQL 配合使用，可以獲得包括但不限于下面列舉的這些好處：

• Django 代替用戶(hù)執(zhí)行繁重的 SQL 任務(wù)（適用于 Flask/FastAPI 的 SQLAlchemy 等工具也是如此）
• Django 可以實(shí)現(xiàn)原始 SQL 命令（SQLAlchemy 之類(lèi)的工具也可以支持）
• Django 可以幫助新手學(xué)習(xí) SQL 命令
• Django 內(nèi)建了對(duì) MySQL 和 PostgreSQL 的支持（還提供了一個(gè)針對(duì) db 的 Python 客戶(hù)端）
• 可提高生產(chǎn)環(huán)境的部署速度
• 可提高可靠性與可恢復(fù)性
• 有助于為開(kāi)發(fā)和生產(chǎn)環(huán)境提供幾乎完全一致的數(shù)據(jù)庫(kù)技術(shù)
• 讓基于容器的 Django 更易用、更可靠
• 實(shí)現(xiàn)了從單節(jié)點(diǎn)部署到多節(jié)點(diǎn)的擴(kuò)展，甚至可全面過(guò)渡至 Kubernetes
• 幫助 Django/Python 新手更容易地使用生產(chǎn)級(jí)系統(tǒng)
• 更易于跨多個(gè) Python 應(yīng)用共享數(shù)據(jù)庫(kù)，并且更安全（例如 FastAPI 應(yīng)用讀 / 寫(xiě)基于 Django 的 MySQL 數(shù)據(jù)庫(kù)）
• Django 的 JSONField 現(xiàn)已支持使用 MySQL（以前只支持 PostgreSQL）
• 更易于測(cè)試（在 CI/CD 期間，或在本地開(kāi)發(fā)環(huán)境中）
• 規(guī)模完全可滿(mǎn)足 Django 的需求
• 支持在一個(gè) Django 項(xiàng)目中使用多個(gè)數(shù)據(jù)庫(kù)，例如使用 MySQL 作為主要的讀 / 寫(xiě)數(shù)據(jù)庫(kù)，并用另一個(gè) MySQL 為常用查詢(xún)提供可讀副本數(shù)據(jù)庫(kù)
• 嚴(yán)格的訪(fǎng)問(wèn)控制（Linode Private IP、本地開(kāi)發(fā)）
• 要求通過(guò) SSL 證書(shū)進(jìn)行連接（增加了部署復(fù)雜度，但也增強(qiáng)了安全性）
• 實(shí)現(xiàn)私有連接（同一區(qū)域內(nèi)部，降低連接成本）

這篇文章的內(nèi)容感覺(jué)還行吧？有沒(méi)有想要立即在 Linode 平臺(tái)上親自嘗試一下？別忘了，現(xiàn)在注冊(cè)可以免費(fèi)獲得價(jià)值 100 美元的使用額度，快點(diǎn)自己動(dòng)手體驗(yàn)本文介紹的功能和服務(wù)吧↓↓↓

出海云服務(wù)，選擇Akamai Linode！

歡迎關(guān)注 Akamai，我們將定期分享各種實(shí)用技巧，幫助大家了解如何通過(guò)現(xiàn)代方法在 Linode 上部署 Django 應(yīng)用程序，如何更好地使用托管的 MySQL 數(shù)據(jù)庫(kù)，如何通過(guò) GitHub Actions 實(shí)現(xiàn) CI/CD，以及與 Terraform、Ansible 等技術(shù)有關(guān)的各類(lèi)實(shí)用技巧。