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

-

前言

我們會用到前六篇文章的內容，創造一個真實實務的Docker體系，包含

  • 開發
  • 測試
  • 部屬

工具

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

  • GitHub
    • 包含master和feature觀念
  • Travis CI
    • 由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中

Docker 在哪?

其實我們並不會真的使用到Docker，我們只會用Docker讓這過程變得簡單

開始開發環境

開始前知識

  • npm run start
    • 啟動react app可以馬上看到畫面
  • npm run test
    • 執行單元測試
  • npm run build
    • 將分散的js包裝成一個js檔，通常開發完放上生產環境就是這包js

為何要選擇ract而不是python?java原因很簡單，npm比較方便

建立React專案

只要找到目標資料夾，輸入

npx create-react-app my-app

就可以看到我們React app專案建好了，接下來的操作都會在這個資料夾的根目錄進行操作

創立Dockerfile

這個環節的Dockerfile我們會加上.dev，為了強調這是在開發環境時的Dockerfile，所以裡面的Image配置也會是以開發環境為主

Dockerfile.dev

FROM node:alpine

WORKDIR '/app'

COPY package.json .
RUN npm install

COPY . .

CMD  ["npm", "run", "start"]

這裡我們呼叫的docker build .必須做一點小小的改變

docker build -f Dockerfile.dev .

告訴docker我們要他依照有.dev的版本去創建image

啟動

使用

docker run -p 3000:3000 image-id

我們就可以看到我們範例的react app可以透過瀏覽器使用了

Volume

如同port的映射，Volume的變數就是將本機的File映射到Docker File體系中。

作為範例我們改掉src/App.js中的p標籤中的字串，改成hi there

import React, { Component } from 'react';
import logo from './logo.svg';
import './App.css';

class App extends Component {
  render() {
    return (
      <div className="App">
        <div className="App-header">
          <img src={logo} className="App-logo" alt="logo" />
          <h2>Welcome to React</h2>
        </div>
        <p className="App-intro">
          Hi there!
        </p>
      </div>
    );
  }
}

export default App;

在將之前啟動的指令改為

docker run -p 3000:3000 -v $(pwd):/app image-id

啟動後我們可以看到web app中的內容已經跟著改變，不需要重新build一次image

指令好複雜好麻煩- Docker compose

docker-compose.yml

version: '3'
services:
    web:
        build:
            context: .
            dockerfile: Dockerfile.dev
        ports:
            - "3000:3000"
        volumes: 
            - /app/node_modules
            - .:/app
  • build變數的拆解
    • context:告訴docker-compose要build檔案(環境) 這邊我們直接取目前目錄(docker-compose所在的目錄)
    • dockerfile:告訴docker-compse要以哪個dockerfile作為image的設定檔
  • volumes
    • 我們排除掉了node_modules (因為沒有聲明本機的modules資料夾所以不會做映射)，為什麼要排除?因為modules只是我們開發過程的工具，在最後start或build時並不會真的參與

在我們的資料夾下加上了這個docker-compose.yml後就可以輕鬆的docker-compose up了

開始測試

之前透過busybox有嘗試過在container run指令後增加command line指令，讓container執行，

docker run -it image-id npm run test

這樣我們在啟動conatiner時，就可以同步測試了。

建立生產環境

生產環境和開發環境最大的差別在於我們會以Nginx當作server，所以在這環節我們會多了如何讓Nginx進入Docker並且將我們的build裡面的內容放置於Ngnix中

下圖是我們要做的事情

我們只需要在專案根目錄新增一個Dockerfile就好，這次不需要再加上.dev因為這是我們生產環境要使用的Dockerfile

FROM node:alpine as builder

WORKDIR '/app'

COPY package.json .
RUN npm install

COPY . .
RUN npm run build

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

可以看到前面的設定都跟開發環境一至，差別在於我們需要讓第一個container執行build產出生產結果，並且將結過複製到nginx的server之中，新增完dockerfile之後啟動就好了

docker run -p 8080:80 image-id

nginx沒有啟動的log所以我們直接到我們的8080 port去看就可以看到結果

總結

Docker實務開發有分上下兩級，這一級我們介紹了基本的開發環境Docker的設定，在後面我們引入了Nginx當作生產環境，下一集會介紹如何將GitHub CI和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的寫入是依靠硬碟的而快取是依靠記憶體，有基本計算機常識的話就可以知道...
閱讀完整內容