後端打工仔,在下班後喜歡研究各種不同的技術。稍微擅長 PHP,並偶爾涉獵前端開發。個性就像動態語言般隨興,但渴望做事能像囉嗦的靜態語言那樣嚴謹。
Hello ~
當你的 Laravel App 與資料庫容器啟動之後,就可以使用 artisan migrate 來建立 Laravel App 需要的資料表。
artisan migrate
但注意資料庫要先新增好,我是直接使用 MySQL 官方的 docker image,在啟動時可以藉由設定環境變數來新增資料庫與使用者,詳細可以參考我部署用的 k8s yaml 檔案。
因為是在 production 環境,artisan migrate 應該會詢問你是否真的要在 production 環境執行該指令,直接確認即可。
但假如你已經有資料了,可以將資料使用 mysqldump 匯出一份 .sql 檔案,日後建立好資料庫後直接匯入 .sql 就好,就不用再使用 artisan migrate。
.sql
寫一篇遊戲心得真的很花時間 😰。
下一篇預計來寫薩爾達傳說:王國之淚!!!
需要方便的 auto scaling,就要左轉去找 EKS、AKS 或是 GKE 了。
但本篇文章要做 auto scaling 應該也是可以的。
以 AWS 為例,你可以建立一個 auto scaling group,並設定閾值 (例如 CPU 使用率達到多少),當達到閾值時就開啟一台新的機器,並執行預先寫好的 user data,將新機器以 agent 的身份加入到 k3s cluster 中。
這應該是個可行的方案,但個人覺得如果有 auto scaling 的需求,還是建議使用更專門的 k8s 雲端服務會更好。
Docker compose 並不是拿來製作容器的。
當你的服務需要多個容器同時運行時,例如 web app、資料庫與 redis,你可以使用 docker compose 一起啟動它們,並將這些服務放在同一個虛擬網路層中,使其可以互相連線。
基本上有加上 cache 的話,就能大幅度減少 build 的時間
用戶上傳的檔案我放到 S3 上面。
而資料庫的部分,我有使用 k8s 提供的 persist volume。
Laravel 相關的 App (包含 horizon 與 scheduler),我都沒有在 k8s 上面使用 volume 存放 storage 的資料。
因為 cache 的 driver 我是選擇用 Redis,所以就算 Laravel App 有多個 replica,都可以從 Redis 上獲取 cache。比較重要的 cache 如使用者登入的 session,並不會存放在 storage 資料夾中。
沒有單獨的專案,但可以參考我的部落格原始碼。
Base image 我改成用 Alpine Linux,內容上會有些不同。
之前部落格就是很簡單的用 docker 跑起來,所以有參考你的文章 😆
[Go 教學] graceful shutdown 搭配 docker-compose 實現 rolling update
再次感謝大大的分享~
這方面的資料真的偏少。但我個人認知兩者是可以並存來提高請求的處理速度。
Opcache 是將 Bytecode 儲存在記憶體中,等到下次同樣的程式碼執行時,PHP 可以直接到記憶體拿 Bytecode 執行,省下將程式碼轉換成 Bytecode 的步驟。
Swoole 是啟動多個 Worker 來處理請求,每一個 Worker 都有自己的記憶體,但是彼此間可以透過 Swoole Table 共享記憶體。
在官方文件的使用問題中,就有在測試 Swoole 性能時,同時開啟 Opcache,所以我想兩者是可以同時並存來提高請求的處理速度。
顯示中 1 至 10 於 22 結果
Hello ~
當你的 Laravel App 與資料庫容器啟動之後,就可以使用
artisan migrate
來建立 Laravel App 需要的資料表。但注意資料庫要先新增好,我是直接使用 MySQL 官方的 docker image,在啟動時可以藉由設定環境變數來新增資料庫與使用者,詳細可以參考我部署用的 k8s yaml 檔案。
因為是在 production 環境,
artisan migrate
應該會詢問你是否真的要在 production 環境執行該指令,直接確認即可。但假如你已經有資料了,可以將資料使用 mysqldump 匯出一份
.sql
檔案,日後建立好資料庫後直接匯入.sql
就好,就不用再使用artisan migrate
。寫一篇遊戲心得真的很花時間 😰。
下一篇預計來寫薩爾達傳說:王國之淚!!!
需要方便的 auto scaling,就要左轉去找 EKS、AKS 或是 GKE 了。
但本篇文章要做 auto scaling 應該也是可以的。
以 AWS 為例,你可以建立一個 auto scaling group,並設定閾值 (例如 CPU 使用率達到多少),當達到閾值時就開啟一台新的機器,並執行預先寫好的 user data,將新機器以 agent 的身份加入到 k3s cluster 中。
這應該是個可行的方案,但個人覺得如果有 auto scaling 的需求,還是建議使用更專門的 k8s 雲端服務會更好。
Hello ~
Docker compose 並不是拿來製作容器的。
當你的服務需要多個容器同時運行時,例如 web app、資料庫與 redis,你可以使用 docker compose 一起啟動它們,並將這些服務放在同一個虛擬網路層中,使其可以互相連線。
基本上有加上 cache 的話,就能大幅度減少 build 的時間
用戶上傳的檔案我放到 S3 上面。
而資料庫的部分,我有使用 k8s 提供的 persist volume。
Hello ~
Laravel 相關的 App (包含 horizon 與 scheduler),我都沒有在 k8s 上面使用 volume 存放 storage 的資料。
因為 cache 的 driver 我是選擇用 Redis,所以就算 Laravel App 有多個 replica,都可以從 Redis 上獲取 cache。比較重要的 cache 如使用者登入的 session,並不會存放在 storage 資料夾中。
沒有單獨的專案,但可以參考我的部落格原始碼。
Base image 我改成用 Alpine Linux,內容上會有些不同。
之前部落格就是很簡單的用 docker 跑起來,所以有參考你的文章 😆
[Go 教學] graceful shutdown 搭配 docker-compose 實現 rolling update
再次感謝大大的分享~
這方面的資料真的偏少。但我個人認知兩者是可以並存來提高請求的處理速度。
Opcache 是將 Bytecode 儲存在記憶體中,等到下次同樣的程式碼執行時,PHP 可以直接到記憶體拿 Bytecode 執行,省下將程式碼轉換成 Bytecode 的步驟。
Swoole 是啟動多個 Worker 來處理請求,每一個 Worker 都有自己的記憶體,但是彼此間可以透過 Swoole Table 共享記憶體。
在官方文件的使用問題中,就有在測試 Swoole 性能時,同時開啟 Opcache,所以我想兩者是可以同時並存來提高請求的處理速度。