[微服務] Docker基礎(8) - 讓Docker進入實務的專案(二)

-

前言

我們會延續第七篇的內容，創造一個真實實務的Docker體系，包含

  • 開發
  • 測試
  • 部屬

工具

在這個實務專案我們會用到

  • GitHub (Free)
    • 包含master和feature觀念
  • Travis CI (Free)
    • 由GitHub提供的CI工具
  • AWS (有免費專案)
    • 我們會將AWS的服務當作最終生產環境
  • React
    • 我們只單純的使用React的初始APP不會做太多的React Code主要是要看到他的畫面

流程

Dev

  • 創建/更新code 在feature branch中
  • 將code merge到master中

Test

  • 將code push到Travis CI中
  • 測試程式碼

Prod

  • 將PR merge進master中
  • 測試
  • 部屬到AWS Beanstalk中

這篇文章會著重於，將Code推上GitHub透過Travis部屬至AWS平台

讓你的專案和GitHub連接

先到你的GitHub創立一個Repository
在到上篇文章的React app和GitHub連接

git init
git add .
git commit -m "First commit"
git remote add origin 你的.git連結
git push origin master

就完成專案和GitHub的連接了

Travis

直接用GitHub的SSO登入Travis，並且透過官方的基本操作將目標Repository拉到Travis工作區

接下來我們要

  • 透過Travis跑我們的Docker.dev環境
  • 告訴Travis我們要跑測試

只要在上一篇(七)的文章中我們前置作業做好的React App資料夾中加上.travis.yml檔案就可以開始使用travis的功能

將GitHub的專案拉到Trais工作區
登入Travis後點擊右上角的帳號setting就可以將自己的範例專案拉到工作區，如下點擊我們這範例的Docker react專案

接下來Travis只要新增下面的檔案到自己專案的根目錄，每次push上去就會幫你建置搂!

.travis.yml

sudo: required
services:
    - docker

before_install:
    - docker build -t charlie/docker-react -f Dockerfile.dev .

script:
    -  docker run charlie/docker-react npm run test -- --coverage
  • sudo是告訴Travis要用根權限操作
  • services是宣告會用到那些服務
  • berfore_install當執行我們要做的script前我們要先做那些操作
  • script是我們要做哪些事情
    • 這裡我們多了-- --coverage是要透過npm幫我們看單元測試的覆蓋率

記得要將此檔案推到GitHub上
推上Github後，更新Travis的畫面，就可以看到我們的單元測試開始跑了!

AWS

我們這裡會使用到AWS的Elastic Beanstalk，在控制台尋找Elastic Beanstalk簡單的輸入專案名稱並且宣告自己使用是Docker platform，其他使用預設就好

在這裡不深入探討如何使用Elastic Beanstalk，之後會再增加介紹文章

新增EBS一個新的Server，並且選擇Docker專案

透過AWS使用介面尋找S3的服務並且記錄S3的bucket name

我們要對Elastic Beanstalk做甚麼呢?

  • 我們要將我們的Docker容器放進去並且啟動
  • 我們要進入S3我們EBS(Elastic Beanstalk)拿取我們的Bucketname
  • 進入IAM特別開一個專屬於這個EBS的部屬帳號(記得打開EBS權限)，並且拿取Access和Secret ID
  • 設定我們的.travis.yml檔的部屬設置

過程結束後我們的.travis.yml會長這個樣子

sudo: required
services:
    - docker

before_install:
    - docker build -t charlie/docker-react -f Dockerfile.dev .

script:
    -  docker run charlie/docker-react npm run test -- --coverage

deploy:
    provider: elasticbeanstalk
    region: "us-east-1" 
    app: docker-react
    env: "DockerReact-env"
    bucket_name: "從S3拿到的BucketName"
    bucket_path: "docker-react"
    on:
        branch: master
    access_key_id: $AWS_ACCESS_KEY
    secret_access_key:
        secure: "$AWS_SECRET_KEY"
  • deploy 是告訴travis我要如何部屬
    • provider 標明我們要部屬在EBS中
    • region 是我們EBS所在的區域
    • app 就是我們EBS所開的專案名稱
    • env 此專案所在的環境
    • bucket_name 從S3得到和這個EBS連接的儲存裝置名稱
    • bucket_path 打上我們的專案名稱(他會直接幫你以專案名稱作為App的根目錄資料夾)
    • on
      • branch 我要針對哪一個branch變動時作部署
    • access_key_id 我們要連進EBS的進入金鑰
      • 裡面的$AWS_ACCESS_KEY是透過travis專案裡面setting的environment設定
    • secret_access_ley
      • secre 同上透過環境變數設定

再來是記得打開我們Dockfile Nginx的port，因為EBS上我們不能透過docker run -p的方法設定要打開的port，所以只能透過docker裡面設定

dockerfile

FROM node:alpine as builder

WORKDIR '/app'

COPY package.json .
RUN npm install

COPY . .
RUN npm run build

FROM nginx
EXPOSE 80
COPY --from=builder /app/build /usr/share/nginx/html

再將這次更動push到我們的github上，等一下部屬時間，就可以看到我們的react app成功發布到AWS EBS上，恭喜你完成第一個簡單的實戰應用，之後如果要在上面開發你已經做到了第一個CI/CD搭配Docker的自動架構了

結論

這兩篇文章從打包React到Docker，設定Dockerfile/Dockerfile.dev還有travis的自動化測試，以及最後將整個App部屬至AWS上

留言

張貼留言

這個網誌中的熱門文章

Java Lambda Map篇

-
目的 主要介紹Map中的新方法，包含如下 forEach() getOrDefault() putIfAbsent() remove() replace() replaceAll() merge() 有些是Lambda有些則是我覺得比以前使用Map更方便而介紹 forEach Map的forEach方法與List不大依樣，因為Map主要的迭代方法是以Entry為主，所以需要Key-Value Pair去迭代 原始碼解說 可以看到forEach的傳入參數BiConsumer介面，必須傳入Key與Val，裡面的實作就如同我們使用Java8版本以前的寫法，需要使用for迴圈去迭代抓出每個Value 原始碼 default void forEach(BiConsumer<? super K, ? super V> action) { Objects.requireNonNull(action); for (Map.Entry<K, V> entry : entrySet()) { K k; V v; try { k = entry.getKey(); v = entry.getValue(); } catch(IllegalStateException ise) { // this usually means the entry is no longer in the map. throw new ConcurrentModificationException(ise); } action.accept(k, v); } } 範例 private void forEachExample() { Map<Integer, String> map = new HashMap<>(); map.put(1, "test1"); map.put(2, "test2"); m...
閱讀完整內容

設計模式 - 工廠模式 (Creational Patterns - Factory Pattern)

-
圖片
前言 這篇文章會介紹三個最常使用的工廠模式方法，分別是 Simple Factory (簡單工廠) Abstract Factory (抽象工廠) Factory Method (工廠方法) 其中最容易讓人搞混的是，Abstract Factory和Factory Method，不過對我來說何必太過糾結於這兩個的概念，工廠模式最主要的核心原理就是將你創造物件的邏輯隱藏起來，不向客戶端顯示，我覺得只要知道這個概念就夠了，接下來會介紹這三個種類的工廠模式。 Factory Pattern 工廠模式 Simple Factory 簡單工廠 簡單工廠是工廠模式的第一步，也是工廠模式最基本的核心概念實踐，主要解決的問題是 將創建物件邏輯抽離 解偶Class的複雜度 Class Diagram 將封裝物件邏輯抽出寫成Simple Factory 產出父類別物件的物件 範例 在這個範例我們希望將戰士與魔法師遊戲創造英雄的邏輯抽出並且寫成靜態工廠，戰士與魔法師都是英雄並且’目前’只能進行攻擊，程式碼如下 Interface Hero public interface Hero { void attack(); } Magician.class public class Magician implements Hero { @Override public void attack() { System.out.println("Use magic to attack"); } } Warrior.class public class Warrior implements Hero { @Override public void attack() { System.out.println("Use sword to attack"); } } HeroFactory.class public class HeroFactory { public Hero makeHero(HeroType heroType) { if (heroType.equals(HeroType.MA...
閱讀完整內容

(InterviewBit) System Design - Design Cache System

-
圖片
前言 這是InterviewBit中Storage Scalabiliy第一題，設計一個快取系統。 我希望可以透過InterviewBit中的文章與題目，打開自己系統設計的視野，並且重裡面中得到關鍵詞彙，透過這些關鍵詞彙補足自己知識的不足。 其中會參考許多 jyt0532神 的許多文章 題目 替Twitter或是google設計快取系統，概念圖如下: 分析步驟 列出需求情境 估算 立定設計目標 深入探討設計方法 需求情境 需要多大的快取 我們的快取清除策略要如何 因為快取大小所以必須將舊資料刪掉 快取的寫入策略 Write through cache 當資料寫入時，同時寫入DB和Cache中 寫入因為需要寫入兩個系統(DB/Cache)所以有較高的延遲 Write around cache 當資料寫入時先寫入DB，當快取被讀取發現遺失資料時，再將資料從DB同步到快取中 因為讀取是從快取中讀取，但是在讀取時判斷到有新增資料沒進入快取，會有較高的讀延遲。 但寫和重複讀不會有特別的延遲 Write back cache 直接將資料寫入到快取中，在同步到資料庫裡 風險 - 畢竟快取是in-memory會有遺失風險 優點 - 高寫入效率(寫得快可附合的流量大) 可以透過replica快取降低memory消失的風險 評估 預先知識 QPS - Queries Per Second TPS - Transactions Per Second UV - Unique Visitor RPS - Requests Per Secornd 獲取設計前條件 目前得知的條件 快取大小會是30TB QPS會是10M(每秒一千萬) 估算機器數量 假設我們每台機器都有72G的記憶體，則要存入30TB的資料則需要 30TB / 72G = 420(大約)，而這是剛剛好的數目，有可能需要增加，因為我們每秒要附和10M的搜尋流量。 設計目標 設計目標三巨頭 Latency(延遲) Consistency(一致性) Availability(可使用性) 快取系統的設計目標 快取的用意就在於降低延遲，DB的寫入是依靠硬碟的而快取是依靠記憶體，有基本計算機常識的話就可以知道...
閱讀完整內容