docker as engitor及雲建構devops選型

本文關鍵字:docker as engitor,雲建構devops

在釋出《engitor as demo show engine,applet container》時，我們談到engitor是一種延續langsys，獨立于開發，但對接開發增強開發，及負責整個釋出和部署,甚至運作（除了xaas層次的那部分運作）的綜合過程統稱，解決開發完成後，增強開發環境，問題域demo組裝及釋出至上線的一系列後續工作。類似應用伺服器，但不止這些。比如vs appserver,an engitor可以是強化語言系統之後可視化的開發增強支援(engitor=app engine as editor)甚至提供baas，paas這樣的運作增強支援，而傳統appserver僅負責特定的部分。

我們總把整個軟體工程分為xaas,langsys,engitorx(appdomain),apps四個層次。越到最後規模越小，程式邏輯越片斷化具體領域化，最終，它使源碼形式的語言系統寫出的源碼片斷程式，可以以可視化的形式開發，碎片化釋出/累積的方式運作，使得練習和示範可以向最終應用逐漸無痛地疊代。。我們一直在為這些領域選型。如上所述，appdomain的engitor承上啟下是規模較大的一塊，其選型也就越複雜。

在那裡，我們主要選取了jupyter和openresty來說明engitor：

1)在用jupyter充當這個engitor時它同時是enginx，它的特點是.ipynb，技術上這實際上是一種web腳本和各種語言後端的服務環境"web engitor"(但是它支援cs app化engitor)，.pynb可以欠在webviewer中也可以欠在其它支援jupyter cs協定（類似cgi）的clientview中，由于engitor是支援多語言的。是以，它實際上是将多種語言源碼片斷(a note)統一釋出成web應用的服務端腳本的形式并将執行結果傳回。這其實就是動态web腳本的理念。但是它第一次實作了将不同的語言統一化為服務端腳本，且提供了一個線上IDE(以開發一段note測試一段note的行為)。而實際上足夠複雜的ipynb是可以開發app的，也不限于用線上IDE的教育工具的形式去展現,其前後端一個是語言一個是應用就像普通WEB一樣。

2)而openresty的enginx是純運作方面的engitor選型，我們在《釋出enginx中》，提到元件伺服器環境，它使服務性程式的協定部分，變成元件的互動。将lamp,lnnp,lnmp結構擴充到可配置的通用元件化伺服器程式的結構(實際上是利用lua為nginx寫腳本)，而kbengine這樣的結構就示範了如何用openresty來充當通用程式的enginx-game app

legacy engitor和devops雲建構

以上選型都有幾個共同的特點，1,在這種engitor是一個組裝運作環境，這種語言環境“線上收集合成了”使用者碎片化方式送出的源碼邏輯，是個雲建構化的開發環境類程式。2，且形成的engitor app要在這個engitor輔助下運作，因為它要面向源碼片斷輸出這種源碼下的應用。這此都符合我們對engitor選型的一慣要求和标準。

那麼是否能建構一個engitor，它依然能夠面向對一端是語言src邏輯輸出另一端是應用輸出而不局限僅用于要求輸入端必須是源碼，輸出端必須是APP？(一言以蔽之通用化建構任意程式)，且不要求運作在以上具體engitor下？那麼這還叫engitor嗎？還有意義嗎？

畢竟，我們想得到一個萬用的engitor，将傳統上從(linux的生态開始處,CUI處，那個時候僅有os kernel和toolchain)，将任何複雜應用的開發涉及到的多種語言源程式/二進制的編譯過程，多種語言vm的打包過程自動化起來，将這些在傳統上是建構腳本的編排技術，和OS的包管理技術考慮進來，甚至使建構本身雲化和建構服務外部化雲化，喂給遠端建構-雲建構，。形成自動化，雲端腳本化編譯的結果，并以此為運作目标，僅負責書寫最終APP上的事。

這實際上就是輸入端接受任意建構，輸出端産生任意程式的單一要求而已。這樣的engitor實際上以os為enginx運作，以能運作上其上的所有可能語言系統為engitor中的langsys。而engitor也不必是個jupyter+web執行環境式的“雲建構”和中間件打包。比如，它可以是任何程式（非源碼形式的某語言源碼片斷,二進制也可，非IDE類産出過程也可）構成的“雲建構”和中間件打包。它可以沒有任何關乎engitor意義上的輸入輸出。但是依然可以适用于engitor特例。

那麼如何整合這些，這實際就是devops做的事。傳統我們在PC上用各種開發用的虛拟機vagrant，那麼我們現在有docker和devops

docker as engitor和雲IDE。

在那文中我們講到jupyter也有jupyter hub。實際上它相當于docker版本的github+dockerhub組成的devops。

docker as 通用建構技術和容器的情況下，實際上docker與docker-compose是二個獨立的過程，docker隻負責run，而github相當于ide中收集源碼的工程環境，那麼我們還可以得到什麼呢？

比如結合前面的ellie，我們可以在結合docker和gitlab cl for elmlang的情況下，把這個ellie ide放進去。做一個雲IDE。

自由大開腦洞去吧。

(此處不設回複，掃碼到微信參與留言，或直接點選到原文)