在本地端試驗成效不錯後，就想著如果可以佈署到雲端進行使用，日後利用Strapi進行遊戲資料讀取時的管理也應該是相當方便的。在這樣的考量下，就花了些時間試著將Strapi推上雲端服務。先說結果，Strapi佈署到雲端了，但不能用。接下來才細說中間碰到的問題。

試著佈署到雲端的過程

目前碰到的問題是在於要將Strapi架設到雲端時，沒有完整的教學。雖然Strapi官方在Deployment有針對數個主流的平台進行說明。但選擇的Render佈署文件裡，並沒有對於太詳細的說明。

看了這篇How I Hosted my Strapi CMS Driven Website for Free後，想著Heroku免費的方案有佈署上有不少地方要自行打點，先用小額的雲端付務進行，付費的多半會比較容易。

首先，對於提供的多個主流雲端的選擇來看，Render算是性價比相當好的一個選擇。故在比較後則以此服務為首選。但Strapi佈署到Render裡的文件中，雖然有對於不同的使用情況進行解說。然而，實際進行操作時，才發現這只能將Strapi以Production的方式佈署到Render上。但在後台無法於Production的環境使用下，勢必要進行Staging環境的佈署。而這個環境不論是Strapi的文件，或是位於Render中佈署Strapi的文件都沒有詳細的說明。

考量到前端是以Gatsbyjs進行static content generation的Blog，故以render-examples / strapi-sqlite當做基礎。到這裡，已經是Render提供的範本專案。自行fork後進行佈署，之後增減、調整API的修正就回推到Git Repo，也看到Render端會進行build和deploy的動作。然佈署的環境仍是Producation，故無法利用後台介面進行內容物的調整。

反覆的看了Strapi和Render端各自提供的文件，都對於這部份沒有太多的著墨。雖然看到了Render端的文件裡有寫到

If you’d like to set up a staging environment on Render, you can update the render.yaml file at the root of your repository and add staging resources that are similar to your production resources.

但對於實際這份render.yml怎麼寫才能架設出staging環境並和現有的producation環境共用資料，其實不是很理解。

利用sqlite當做資料的存取方式就我的理解它是檔案架構的，而多數的staging和production環境，是二個不同的入口，但可能會/不會共用一個db。但先不論共用同一個db是否安全。但在sqlite的架設方式裡，二個不同的入口，一個是staging、一個是producation，怎麼看sqlite就是二份。就算是架設了一個staging的web service，含有一套sqlite，透過Strapi的後台加入了新的資料後，前台(Blog)若是按照分環境的概念，那就是直接連去production環境的web service，而這個地方的sqlite資料應該是一直空的。

所以，從這樣的設定上有幾個想法。

  1. 一個在Render上的web service，可以隨時轉換production和staging環境
  2. 不同web service的sqlite，有方式可以互相進行資料sync
  3. 要自行利用render.yml，去調整node的環進設定，改成staging佈署後，修改資料後再改回production環境，再進行佈署
  4. 反正是Blog，直接連staging就好，不需要太複雜

自行調整render.yml裡的node環境進行佈署

第一、二項目前沒有頭緒，不知是否可行。而第三點是目前可以試驗的，而第四點有些部份和第三點有關聯性，所以先從第三點著手進行

查看了目錄結構和了解render.yml後，看到了這是範例專案render.yml裡的其中一段

    envVars:
      - key: NODE_VERSION
        value: 12.18.4
      - key: NODE_ENV
        value: production

而範例專案裡的目錄config下有著這樣的子目錄

  • env
    • production

這裡的想法，若是在render.yml裡NODE_ENV是production，則會使用config/env/production的設定。最快速的方式是二個直接命名成staging後推到Git repo上。

回到Render裡看服務的資料，得到的結論是

  • 就算是同一個Git repo，不同的render.yml設定會產生多個web service
  • 就算是用了Staging，一樣不能再加入Strapi的api

仔細想想後也就覺得很合理。

對Render來說，不論是哪個Git Repo，只要是設定檔不同，自然而然就會產生一個新的服務。而對Strapi來說，所有的Api collection或是其中的field，本來就該在development環境裡處理好，staging就算不是正式對外環境，也不該有任何的變動。

成功的試出Strapi上雲端的過程後，反到是自行思考了其必要性。就Blog的後台來試，其實是不必要的。放在Render上的服務每個月收取7美元，但用到的部份也就是它是放在雲端從任何地方使用都很方便，但對於自用的Blog，不需要協同其它Blog作者的情況下，意義不大，直接放在本地端也沒有什麼不妥。對於其它的使用案例來說，放到Render上也最好是以額外db的方式進行佈署，sqlite的方式不太符合這些案例的需求。而Render上另外開設db是需要額外花費的。總之，一但上了雲端，就不是想著免費的方案，而是在一定的付費之下，要怎麼用才會有最大的效益。

Render Web Service for Strapi

這次將Strapi弄上Render是一次對未來佈署上有著不錯的前置了解，但對於現階段用在Blog上，沒有太大的幫助，尤其是Gatsbyjs這種static site generator的模式，在雲端上進行，也不會比在本地端來的方便。不過，也用掉了Render給的的7天免費試用期，在手邊一時之間沒有什麼可以放上去測試的時間點，看著這7天可以開設很多web service的機會就這樣過去，有點可惜。

By ApprenticeGC