標籤: Docker

.NetCore的ApiGateway +Consul的本機實驗

.NetCore的ApiGateway +Consul的本機實驗

一直以來都知道.netcore可以開始跨平台運作在linux上,因此運作在 docker的container中也是可行的

不過最近因為要研究apigateway,需要模擬infra的架構 ,因此需要在本機環境buildup起來多台主機的模式

沒想到入坑玩了一下,就發現,其實眉眉角角也不少,但來來回回操作後,其實是相對會愈來愈熟悉

首頁,我solution的構成包含了以下幾層 (apigateway還可做loadbalance,再加個nginx就可以, 不是這次的重點)

1.Redis(多台 instance作counter的cache)
2.WebApp(.net core)
3.ApiGateway(.net core + ocelot.net sdk)
4.Consul(service discovery service 作ha)

這次主要研究的機制為 3跟4之間的協作機制
基本上,有了3,預設走configuration就可以手動配置 ,但若要能做到動態ha的話,就必須加入service discovery的機制,剛好ocelot框架有支援 consul(還有其他套,但預設consul)

docker-compose

為了方便 重建,這次採用 docker-compose的yaml來維護(以下情境的container -name 都一般化了,只需要區分角色就好)

version: "3"

services:
  nginx:
    build: ./nginx
    container_name: core-app.local
    ports:
      - "80:80"
      - "443:443"
    depends_on:
      - core-app-gateway1
    # network_mode: "host"
    networks:
      - backend

  consul1:
    image: consul
    container_name: node1
    command: agent -server -bootstrap-expect=2 -node=node1 -bind=0.0.0.0 -client=0.0.0.0 -datacenter=dc1
    # network_mode: "host"
    networks:
      - backend

  consul2:
    image: consul
    container_name: node2
    command: agent -server -retry-join=node1 -node=node2 -bind=0.0.0.0 -client=0.0.0.0 -datacenter=dc1
    depends_on:
      - consul1
    # network_mode: "host"
    networks:
      - backend

  consul3:
    image: consul
    hostname: discover-center
    container_name: node3
    command: agent -retry-join=node1 -node=node3 -bind=0.0.0.0 -client=0.0.0.0 -datacenter=dc1 -ui
    ports:
      - 8500:8500
    depends_on:
      - consul1
      - consul2
    #network_mode: "host"
    networks:
      - backend

  redis:
    container_name: myredis
    image: redis:6.0.6
    restart: always
    ports:
      - 6379:6379
    privileged: true
    command: redis-server /etc/redis/redis.conf --appendonly yes
    volumes:
      - $PWD/data:/data
      - $PWD/conf/redis.conf:/etc/redis/redis.conf
    networks:
      - backend

  core-app-discover-a1:
    build: ./dotnetapp/dotnetapp-discover
    hostname: webapp1
    environment:
      - HOSTNAME=http://0.0.0.0:40001
      - SERVER_HOSTNAME=http://192.168.1.115
      - SERVER_PORT=8500
      - CLIENT_HOSTNAME=http://core-app-discover-a1
      - CLIENT_PORT=40001
      - SERVICE_NAME=core-app-discover-a
      - RedisConnection=redis:6379,password=12345678,allowAdmin=true
    depends_on:
      - redis
      - consul3
    ports:
      - "40001"
    networks:
      - backend

  core-app-discover-a2:
    build: ./dotnetapp/dotnetapp-discover
    hostname: webapp2
    environment:
      - HOSTNAME=http://0.0.0.0:40001
      - SERVER_HOSTNAME=http://192.168.1.115
      - SERVER_PORT=8500
      - CLIENT_HOSTNAME=http://core-app-discover-a2
      - CLIENT_PORT=40001
      - SERVICE_NAME=core-app-discover-a
      - RedisConnection=redis:6379,password=12345678,allowAdmin=true
    depends_on:
      - redis
      - consul3
    ports:
      - "40001"
    networks:
      - backend

  core-app-discover-a3:
    build: ./dotnetapp/dotnetapp-discover
    hostname: webapp3
    environment:
      - HOSTNAME=http://0.0.0.0:40001
      - SERVER_HOSTNAME=http://192.168.1.115
      - SERVER_PORT=8500
      - CLIENT_HOSTNAME=http://core-app-discover-a3
      - CLIENT_PORT=40001
      - SERVICE_NAME=core-app-discover-a
      - RedisConnection=redis:6379,password=12345678,allowAdmin=true
    depends_on:
      - redis
      - consul3
    ports:
      - "40001"
    networks:
      - backend

  core-app-discover-b:
    build: ./dotnetapp/dotnetapp-discover
    hostname: webapp-b
    environment:
      - HOSTNAME=http://0.0.0.0:50001
      - SERVER_HOSTNAME=http://192.168.1.115
      - SERVER_PORT=8500
      - CLIENT_HOSTNAME=http://core-app-discover-b
      - CLIENT_PORT=50001
      - SERVICE_NAME=core-app-discover-b
      - RedisConnection=192.168.1.115:6379,password=xxxxxxx
    depends_on:
      - redis
      - consul3
    ports:
      - "50001:50001"
    networks:
      - backend

  core-app-discover-c:
    build: ./dotnetapp/dotnetapp-discover
    hostname: webapp-c
    environment:
      - HOSTNAME=http://0.0.0.0:50002
      - SERVER_HOSTNAME=http://192.168.1.115
      - SERVER_PORT=8500
      - CLIENT_HOSTNAME=http://core-app-discover-c
      - CLIENT_PORT=50002
      - SERVICE_NAME=core-app-discover-c
      - RedisConnection=192.168.1.115:6379,password=xxxxxxx
    depends_on:
      - redis
      - consul3
    ports:
      - "50002:50002"
    networks:
      - backend

  core-app-gateway1:
    build: ./dotnetapp/dotnetapp-gateway
    hostname: gateway1
    environment:
      - HOSTNAME=http://0.0.0.0:20001
      - SERVER_HOSTNAME=http://192.168.1.115
      - SERVER_PORT=8500
      - CLIENT_HOSTNAME=http://192.168.1.115
      - CLIENT_PORT=20001
      - SERVICE_NAME=core-app-gateway1
    depends_on:
      - consul3
    ports:
      - 20001:20001
    networks:
      - backend

networks:
  backend:
    driver: bridge

以上yaml就會建立一個network讓 container之前可以用 hostname來通訊。

這次研究的過程,會發現一件事情就是若要綁service discovery,那麼每個末端的webapp都需要跟register center做註冊,並提供一個health接口。但是若要做到auto scale,那依賴docker-compose所做的scale就會綁定動態的host_name(有序號),因此在此不建議 用scale直接長n台容器,而是先用多個端點來建置(如我的a1、a2、a3三台)
這樣就可以指定 hostname跟port給 webapp,而不會被scaling的機制而無法抓到動態的port跟名稱

.netcore application的Dockerfile

以下是webapp的dockerfile (gateway的打包方式差不多,就不貼了)

FROM mcr.microsoft.com/dotnet/sdk:6.0-alpine AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/sdk:6.0-alpine AS build
WORKDIR /src
COPY ["dotnetapp-discover.csproj", "dotnetapp-discover/"]
RUN dotnet restore "dotnetapp-discover/dotnetapp-discover.csproj"
COPY . ./dotnetapp-discover
WORKDIR "/src/dotnetapp-discover"
RUN dotnet build "dotnetapp-discover.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "dotnetapp-discover.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "dotnetapp-discover.dll"]

為了計數器功能與多台sharing cache,因此這次 還 模擬了一下連redis
而redis的connection string 可以透過 environment variable 注入進來(docker-compose可以另外用.env的檔案來管理不同環境,有興趣可以看 官方文件),而在.netcore的c#程式中,要抓到docker的參數的話可以使用GetEnvironmentVariable來取得設定值

    public static IServiceCollection AddCacheService(this IServiceCollection services)
    {
        var redisConnection = Environment.GetEnvironmentVariable("RedisConnection");
#if DEBUG
        redisConnection = "192.168.1.115:6379,password=xxxxxx,allowAdmin=true";
#endif
        
        services.AddSingleton<IConnectionMultiplexer>(
            ConnectionMultiplexer.Connect(redisConnection)
        );
        return services;
    }

註∶為了反覆測試,才加上allow admin,不然這個開關是很危險的,可以直接flush掉你的所有快取(清空)

Redis記錄的Log型態

註冊Service Discovery

ApiGateway跟WebApp我都有跟Consul註冊Service Discovery
因此這次主要的寫法也是follow consul client sdk的套件,Consul的註冊管理上,同一個Name的會被Grouping起來,ID要給不一樣的,若ServiceName都不一樣,就算是一樣的程式,還是會被視為不同節點,這樣會無法作HA的判斷

static void RegisterConsul(string serviceName, string serverHostName , string serverPort, string clientHostName , string clientPort, IHostApplicationLifetime appLifeTime)
{
    using var consulClient = new Consul.ConsulClient(p => 
        { p.Address = new Uri($"{serverHostName}:{serverPort}"); });
    var registration = new AgentServiceRegistration()
    {
        Check = new AgentServiceCheck()
        {
            Interval = TimeSpan.FromSeconds(10),
            HTTP = $"{clientHostName}{(clientPort == string.Empty ? "" : $":{clientPort}")}/health",
            Timeout = TimeSpan.FromSeconds(5),
            Method = "GET",
            Name = "check",
        },
        ID = Guid.NewGuid().ToString(),
        Name = serviceName,
        Address = Dns.GetHostName(),
        Port = int.Parse(clientPort),
        
    };

    try
    {
        consulClient.Agent.ServiceRegister(registration).Wait();
    }
    catch (Exception e)
    {
        Console.WriteLine(e);
    }

    //web服務停止時,向Consul解註冊
    consulClient.Agent.ServiceDeregister(registration.ID).Wait();
}

以上function可以在program.cs的startup時期先進行註冊,而這個function所有的參數一樣可以來自於 docker-compose
範例∶

自動生成HealthCheck端點

在webapp的startup可以使用以下語法就長出health接口

builder.Services.AddHealthChecks();

app.MapHealthChecks("/health",  new HealthCheckOptions()
{
    ResultStatusCodes =
    {
        [Microsoft.Extensions.Diagnostics.HealthChecks.HealthStatus.Healthy] = StatusCodes.Status200OK,
        [Microsoft.Extensions.Diagnostics.HealthChecks.HealthStatus.Degraded] = StatusCodes.Status200OK,
        [Microsoft.Extensions.Diagnostics.HealthChecks.HealthStatus.Unhealthy] = StatusCodes.Status503ServiceUnavailable
    }
});

但還是要視服務加上MapHealthChecks的ResultStatus的設定,以consul來說,就是回200就好了,若沒有加上這個設定,其實health的回應並不是200,所以會被視為失敗

正常情況打 health的接口

Ocelot的設定檔

最後就是ocelot的json設定,傳統的Ocelot自已就有Load-Balance機制,因此若有多台Downstream的服務,本來就可以用以下設定去管理服務

不過這樣做的缺點就是若隨時要增減 容器/主機時,都要再去重新配置設定檔。造成主機可能的reset與維運上的難度,因此透過Service Discovery的好處就浮上了臺面!以下的配置,只需要注意,不用定義DownStream的Host,只要給一個ServiceName,這個ServiceName要跟WebApp在Startup的時候註冊的一樣。並在最後GloablConfiguration有註冊Service DiscoveryProvider的設定,就可以打通ApiGateway跟Service Discovery之間的便利機制。

{
  "Routes": [
    {
      "DownstreamPathTemplate": "/test",
      "DownstreamScheme": "http",
      "UpstreamPathTemplate": "/newapi/get",
      "UpstreamHttpMethod": [
        "Get"
      ],
      "ServiceName": "core-app-discover-a",
      "LoadBalancerOptions": {
        "Type": "LeastConnection"
      }
    },
    {
      "DownstreamPathTemplate": "/test/list",
      "DownstreamScheme": "http",
      "UpstreamPathTemplate": "/newapi/list",
      "UpstreamHttpMethod": [
        "Get"
      ],
      "ServiceName": "core-app-discover-a",
      "LoadBalancerOptions": {
        "Type": "LeastConnection"
      }
    },
    {
      "DownstreamPathTemplate": "/test",
      "DownstreamScheme": "http",
      "DownstreamHttpMethod": "DELETE",
      "UpstreamPathTemplate": "/newapi/reset",
      "UpstreamHttpMethod": [
        "Get"
      ],
      "ServiceName": "core-app-discover-a"
    }, 
    {
      "Key": "api1",
      "DownstreamPathTemplate": "/test/list",
      "DownstreamScheme": "http",
      "UpstreamPathTemplate": "/newapi/list1",
      "UpstreamHttpMethod": [
        "Get"
      ],
      "ServiceName": "core-app-discover-a"
    },
    {
      "Key": "api2",
      "DownstreamPathTemplate": "/test/list",
      "DownstreamScheme": "http",
      "UpstreamPathTemplate": "/newapi/list2",
      "UpstreamHttpMethod": [
        "Get"
      ],
      "ServiceName": "core-app-discover-a"
    }
  ],
  "Aggregates": [
    {
      "RouteKeys": [
        "api1",
        "api2"
      ],
      "UpstreamPathTemplate": "/newapi/listall"
    }
  ],
  "GlobalConfiguration": {
    "BaseUrl": "http://0.0.0.0:20001",
    "ServiceDiscoveryProvider": {
      "Scheme": "http",
      "Host": "192.168.1.115",
      "Port": 8500,
      "Type": "PollConsul",
      "PollingInterval": 100
    },
    "QoSOptions": {
      "ExceptionsAllowedBeforeBreaking": 0,
      "DurationOfBreak": 0,
      "TimeoutValue": 0
    },
    "LoadBalancerOptions": {
      "Type": "LeastConnection",
      "Key": null,
      "Expiry": 0
    },
    "DownstreamScheme": "http",
    "HttpHandlerOptions": {
      "AllowAutoRedirect": false,
      "UseCookieContainer": false,
      "UseTracing": false
    }
  }
}

上述的ApiGateway一樣用DockerFile把專案包成Image

整合測試

docker-compose up -d –force-recreate

會看到一次起來這麼多服務

http://localhost:20001/newapi/get(透過api gateway打到downstream的service)

這邊多請求幾次會發現machineName一直在webapp1~3跳來跑去,採用load-balance的機制,ocelot會採用你設定的策略進行請求分派

ApiGateway有Aggregation的功能,就是可以把多個Api請求Combine在一起,讓請求變成1次,減少頻寬的消耗,這邊我也做了配置,來試看看吧

出於Ocelot.json的設定檔段落:

透過api gateway的組合讓 多個 Api可以一次 回傳

最後,打了很多次請求後,來總覽一下所有的請求摘要(程式是自已另外撈Redis的Request記錄來統計)

http://localhost:20001/newapi/list(透過api gateway打到down stream的service)

嘗試Docker Stop某一台 Discover-a1的服務,Consul DashBoard馬上就看的到紅點了!

這個時候再去打 之前load-balance的端點http://localhost:20001/newapi/get,會發現machineName會避開stop掉的服務只剩下 webapp1跟webapp3在輪循,因此做到了後端服務品質的保護

小插曲

ID不小心用成了Guid.New,所以會導致重新啟動就又拿到新的ID,造成了多一個Instance。但舊的也活了,因為他們的HealthCheck是一樣的

其實ApiGateway的議題,從Infra的角度上,可以玩的東西還有很多。

像是他也支援RateLimiting, QualityOfService(Polly) , 服務聚合(Aggregation)等機制,都可以從他們的官方文件看到設定方式,算是配置上不算太複雜。

不過 Ocelot在.net這邊發展一陣子後,近一年好像停更了!取而代之的好像是其他語言寫的更強的Apigateway: Envoy。

Envoy資源
https://www.envoyproxy.io/docs/envoy/latest/intro/what_is_envoy
https://www.netfos.com.tw/Projects/netfos/pages/solution/plan/20210111_plan.html

若只是要輕量級的,或是想參考其架構設計的,倒是可以翻github出來看看~

Github∶ https://github.com/ThreeMammals/Ocelot

這次Lab程式碼

若要拿去玩的,請把Ip, Password自行調整一下

一些文章的參考

https://ocelot.readthedocs.io/en/latest/features/servicediscovery.html?highlight=ServiceDiscoveryProvider

https://ocelot.readthedocs.io/en/latest/features/servicediscovery.html?highlight=ServiceDiscoveryProvider#

https://www.uj5u.com/net/232249.html

結合docker swarm 建置ElasticSearch Cluster

結合docker swarm 建置ElasticSearch Cluster

最近因為有要整合ELK方案的需求,因此又再度接觸了這個曾經相當熟悉的工具,還記得那個時候(也才1年多前),還是在2.x版左右,kibana的介面還是長這個樣子的時候。

在先前的公司,有平台團隊專門架設這個服務提供RD團隊整合使用,對於使用是絲毫不陌生,但是建置卻完全沒有經驗。沒想到現在已經轉眼間來到了6.1版本,介面跟架構看起來調整的更鮮艷與簡潔(?),我知道ELK目前在windows上面仍然是有一鍵安裝的版本。對於開發要測試的需求上已經相當足夠(連結),但因為我們目前對外主機主要都是CentOS,因此我這次預計實作如下:

假設我有2台CentOS主機的情境下(一台稱為A Host, 一台稱作B Host),如何透過各別安裝elasticsearch的docker 容器,來串連成elasticsearch 的集群。

同一台的多個容器理論上是相對簡單的,而這邊會遇到的問題,主要的關鍵就是如何解決跨主機間docker容器的通信問題,網路架構也通常都是應用程式間管控較為複雜的一個部分

這邊我打算採用Docker Swarm,Swarm為Docker自行開發的容器調度工具,其中的跨主機建立overlay網路功能看起來是非常符合我的情境需求,由於是Docker平台內建工具,看起來並不需要額外的安裝與學習,因此我先從這套工具開始著手,至於關於其他容器調度工具還包含了,Kubernetes、Mesos等。甚至現在的顯學看起來是Kubernetes(k8s),有許多的討論也直指要如何決定該採用哪種方案。

目前看到這一篇(連結)是相對從各面向都有討論到,有興趣的可以看看

Docker swarm的架構圖(來自Docker官網)

從docker 1.9版開始,DockerSwarm已經是內建工具,因此透過以下指令,就可以將主機宣告成DockerSwarm的Manager主機(第一台總是master嘛)

sudo docker swarm init

若有成功啟動DockerSwarm的話,會提示以下訊息

docker swarm join –token SWMTKN-1-5wsc3yya3e87w2e84jkzbpieubpxr9v6qwnbj87m6t2ynv7kxm-8q5amih216368atw8adklx24f %A Host IP%:2377
這個hint很明顯就是我們可以在其他的Host(稱作Worker),透過以上指令來加入到Manager下的叢集中。同時他是透過A Host的2377 Port來進行串連
但假如希望建立起來的Swarm使用其他Port的話,我們可以使用以下指令來做
docker swarm init –advertise-addr=%A Host IP% –listen-addr %A Host IP%:2377
所以我們也可以使用這句語法檢查,是否有啟動了這兩個Port

sudo netstat -nap | grep ^tcp.*dockerd

正常應該會列出對應的2377與7946

tcp6 0 0 :::7946 :::* LISTEN 28184/dockerd
tcp6 0 0 :::2377 :::* LISTEN 28184/dockerd

接著我們在B Host上,輸入剛剛建立完swarm manager 所提示的加入語法

   docker swarm join –token SWMTKN-1-5wsc3yya3e87w2e84jkzbpieubpxr9v6qwnbj87m6t2ynv7kxm-8q5amih216368atw8adklx24f %A Host IP%:2377

在這邊若有無法加入的情況的話,可以往防火牆先檢查,若是防火牆確定有通(telnet看看),那我這邊有遇到原本怎樣都加入不了,但是重開機、重啟docker後,就可以加入的情況。

若Worker成功加入Swarm的話,我們可以在A Host輸入以下指令確認是否節點都完整

docker node ls

既然A-B Host已經加入了同一個網路架構,接著就是建立覆疊網路

sudo docker network create   –driver overlay  –attachable es_net
註:這邊–attachable 若後續要透過run 語法加入指定網路的話,參數一定要加,是不是Docker Compose就不用加,我不確定
成功建立overlay網路後,我們就可以透過以下指令看到我們的網路已經被建立起來,SCOPE是顯示swarm , Driver是顯示overlay
sudo docker network ls
現在網路架構已經看似完成,接著我們來準備Elasticsearh的服務配置吧
這邊我寫了一個腳本來自動建立elasticsearch的相關目錄,目前只要elasticsearch會異動到的檔案目錄權限要開啟來,否則之後容器啟動後,會有權限例外產生:
腳本中改777的部分都是因為遇到所以加上去的,可以自行改成合適的權限配置。

sudo cd /mnt
sudo mkdir elasticsearch
cd elasticsearch
sudo git init
sudo git remote add origin "http://git server ip/scm/mes/elasticsearch.git"
sudo git pull origin master
sudo mkdir config/scripts
sudo mkdir esdatadir
cd esdatadir
sudo mkdir log
sudo mkdir data
sudo chmod 777 /mnt/elasticsearch/esdatadir/*
sudo chmod 777 /mnt/elasticsearch/config/scripts

cd /mnt/elasticsearch

config下的檔案,因為A, B Host各自擁有自己的獨立硬碟,因此我假設他們的環境配置應該都一致,jvm.options、log4j2.properties、檔案都一樣,只有Elasticsearch的yml檔會有些許差異:

path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
cluster.name: meso_es_cluster1
node.master: true #if worker then mark it
node.name: ${HOSTNAME}
network.host: 0.0.0.0
discovery.zen.ping.unicast.hosts: ["A HOST IP", "B HOST IP"]

以上都完成以後,就是來啟動Docker 容器的時候了,以A Host為例,啟動語法如下,B Host只是改–name成es2

sudo docker run -d -v /mnt/elasticsearch/esdatadir/data:/var/lib/elasticsearch -v /mnt/elasticsearch/esdatadir/log:/var/log/elasticsearch -v /mnt/elasticsearch/config:/usr/share/elasticsearch/config -p 9200:9200 -p 9300:9300 --net=es_net --name es1 --security-opt seccomp=unconfined -e "bootstrap.memory_lock=true" -e ES_JAVA_OPTS="-Xms1g -Xmx1g" --ulimit memlock=-1:-1 elasticsearch:5.6.6

分別執行後,我們可以看到docker ps 下是否狀態是正常在up的。

補充說明,啟動es容器時,我曾經發現會有以下的錯誤訊息:max virtual memory areas vm.max_map_count [65530] is too low(請透過docker logs查看)
這個問題若資源分配問題的話,可以透過以下指令解決:
sudo sysctl -w vm.max_map_count=262144
 但我也有一個疑問,logs是記錄容器內部的jvm的錯誤,但是我是在容器外部下語法可解決,這個原因我確實不清楚就是了..

若都是正常,我們可以透過elasticsearch的Api來檢查我們的es cluster是否有正常運作起來

從瀏覽器輸入A Host IP:9200,會返回相關json資訊,若是如下,我們可以認定cluster有啟動,而且服務版本正確,

可以看到name的部分,就正是各別主機上Docker 容器的name,而cluster_name因為配置所以會一致、而若有正確加入的話,cluster_uuid必須要一致
註:我在實作的時候,就一直遇到B Host啟動的起來,但是他無法加入cluster,所以cluster_uuid一直顯示為_na_,後來竟然是整個docker服務重啟就好了,這個羅生門,讓我相信3R的救命招(Recycle, Reset, Reboot),測試期間,也可以透過docker exec -it B HOST Container IP ping -c 3 A_Host_IP來看看是否可以透過容器內解析出跨主機的另一個同網路下的容器名稱

如何觀察Elasticsearch的Cluster狀態呢?具瞭解在es 2.x版本的時候,有一套es的plugin,叫作kopf,是拿來可以直接透過es api來監控es服務的工具

後來5.x版以後,發現plugin功能被拔掉了,取而代之是獨立的”cerebro“套件可以達成完全一樣的功能,看來是同個作者寫的。

介面如下

只要在Node Address輸入A Host es容器名稱:9200(注意容器互連必須透過容器名稱,而不能只是ip),就可以看到以下的dashboard,相當的方便,除了可以即時監控Node的資源使用狀況,也可以看到目前的index數量與使用狀況、空間

cerebro 這邊,只需要透過以下指令,就可以啟動:

sudo docker run -d -p 9000:9000 –name cerebro –net es_net yannart/cerebro:latest

同場加映Kibana 5.6.6的啟動指令

sudo docker run –name meso-kibana –link es1:elasticsearch –net es_net -p 5601:5601 -d kibana:5.6.6
透過A Host IP:5601啟用Kibana後,就可加入已經自定好的Index pattern來使用囉
將你的Nodejs React Web App Docker化

將你的Nodejs React Web App Docker化

假設目前已選用React的框架,我試驗的這套名叫https://github.com/zuiidea/antd-admin

方案目錄結構如下:

主要react程式都放在src的目錄下

node_modules是在npm install的時候,才會把相依套件安裝在這個目錄裡面

以下步驟的目的主要是希望啟動一個node.js 的web server,將我們的react web啟動後,可以透過外部編修程式來除錯與開發

production環境,不需要另外開放目錄了,而且依正常nodejs 的production build,就也編譯好了,所以不會因為src的code異動而影響!

 

 

1.在webapp的根目錄,建立DockerFile (touch Dockerfile)

# You should always specify a full version here to ensure all of your developers
# are running the same version of Node.
FROM node:7.8.0

# Override the base log level (info).
ENV NPM_CONFIG_LOGLEVEL warn

# Install and configure `serve`.
RUN npm install -g serve
CMD serve -s build
EXPOSE 8000

# Install all dependencies of the current project.
COPY package.json /node-app/package.json
#COPY npm-shrinkwrap.json npm-shrinkwrap.json
# The -g switch installs the Express Generator globally on your machine so you can run it from anywhere.
RUN cd /node-app;npm install

# Copy all local files into the image.
COPY . /node-app

# Build for production. 正式機時,要解除註解重建images,不然會大大影響效能
# RUN cd /node-app; npm run build

2. 建立Docker Images

docker build -t react-test-docker .

3. 啟動Docker Container(註,因為沒有標記production build,所以要指定start的路徑,start後,要加上prefix參數,指定你的web app目錄)
sudo docker run -d \
            -v /mnt/nodejs-app/mesodashboard/antd-admin-dashboard/src:/node-app/src \
            -p 8000:8000 \
            –name react-test-server \
            react-test-docker \
            npm start --prefix /node-app
[Docker] docker-compose定義檔範例

[Docker] docker-compose定義檔範例

當平台漸漸成形,對於外部套件、方案相依性定調以後,每次都要手動建置測試運行環境,即使docker已經把建置動作簡化到一行指令了,但是還是令人覺得瑣碎。

這個時候,docker-compose這個解決方案,大幅的簡化了我們的部署工作:傳送門

它僅需要配置服務定義檔(yml檔名),就可以跟現有的docker images整合,立即建置出所需的架構環境!

version: '2.1'

services:
  memcache:
    image: memcached
    ports:
      - "11211:11211"
    command: memcached -m 1024m

  hadoop:
    image: "sequenceiq/hadoop-docker:2.7.0"
    ports:
     - "8030:8030"
     - "8040:8040"
     - "8042:8042"
     - "8088:8042"
     - "19888:19888"
     - "49707:49707"
     - "50010:50010"
     - "50020:50020"
     - "50070:50070"
     - "5007:5007"
    command: /etc/bootstrap.sh -d

  cassandra:
    image: "cassandra"
    ports:
     - "9042:9042"
    volumes:
     - /mnt/cassandra/data:/var/lib/cassandra
 
  mariadb:
    image: mariadb
    ports:
     - "3306:3306"
    volumes:
     - /mnt/mariadb/data:/var/lib/mysql
     - /mnt/mariadb/config:/etc/mysql/conf.d
    restart: always
    environment:
       MYSQL_ROOT_PASSWORD: 525402040966518776
       MYSQL_USER: ap_user
       MYSQL_PASSWORD: jUqJ75aFbJEU
  
  phpmyadmin:
    image: phpmyadmin/phpmyadmin
    links:
      - mariadb
    environment:
      PMA_HOST: mariadb
      PMA_PORT: 3306
    ports:
     - "8088:80"

  my-python-app:
    depends_on:
     - mariadb
     - cassandra
     - hadoop
     - memcache
    image: python35-app
    volumes:
     - /mnt/python-app/src:/usr/src/app
    ports:
     - "12345:12345"
    command: /usr/src/app/run.sh

註:

1.首先是version,據我所知,目前大部分幾個月前安裝的docker,至少可以支持到2.1,但不見得能支持到3.0的版本。相關upgrade的議題,必須持續survey

2.不需要export的port就不要開,可以透過link或是建立network來進行容器互連

3.可以善用command、environment、volumn等docker支持的掛載與注入的方式來配置容器

4.可以透過現成已build好的image或是動態透過build dockerfile來定義服務。這一段上述例子沒有,有需要時再查使用方式

 

最後,啟動服務群指令(記得加-d,否則會被lock在shell,被script轟炸):

sudo docker-compose up -d

若要下架也很簡單(其他還有run、stop等指令可用)

sudo docker-compose down

 

ELK Stack安裝的眉眉角角-Part3:FileBeat

ELK Stack安裝的眉眉角角-Part3:FileBeat

上一篇尾聲記得我還提到,當時沒有使用FileBeat的原因是因為還沒架起來

結果今天重新從 getting started with filebeat的官網文件(傳送門)重新照表操課了一次

結果意外地就架起來了(所以讀官網文件是何等重要的一件事),雖然成果相當的陽春,但是也很足夠記錄下來

首先-設定檔,僅保留最簡單且最必要的部分

我如往常的在mnt下建立了filebeat的目錄,並加入了/mnt/filebeat/filebeat.yml檔案,內容如下

filebeat.prospectors:
- type: log
  enabled: true
  paths:
    - /var/log/mesocollection/*/*.log
  
  reload.enabled: true
  reload.period: 30s

#-------------------------- Elasticsearch output ------------------------------
output.elasticsearch:
  hosts: ["elasticsearch:9200"]
  template.enabled: false
  index: "meso_sys_localfile_fb"

註:這邊path因為上一篇google 到可以用*追蹤動態目錄(例如以日期、小時分類目錄)的情況,filebeat一樣可以支持,另外關於elasticsearch的index,我們一併在這邊設定好,後續可以透過es的api來檢查寫入的狀況。關於輸入elasticsearch,我們這次與logstash的file寫入少了定義filelds parsing的流程,這一段目前查詢起來,除了general像是apache、mysql等大應用的log格式(所以可以參考他們的log格式,可以省點事),否則可能必須透過filebeat轉接logstash再透過fileter parsing後,才能寫入自定義的fields到elasticsearch的index中。(待查證)

接著key入以下指令,我們就可以把filebeat的image run起來:

docker run -d --link elasticsearch-test:elasticsearch -v /mnt/filebeat/filebeat.yml:/filebeat.yml -v /mnt/python-app/mesocollection/logs:/var/log/mesocollection prima/filebeat:5

接著我們可以觸發一下記錄log的行為,例如call api,我們輸入docker logs的指令追蹤一下看看:

2017/07/31 02:57:30.841300 log.go:116: INFO File is inactive: /var/log/mesocollection/20170731/grpc_server_10.log. Closing because close_inactive of 5m0s reached.
2017/07/31 02:57:30.841296 log.go:116: INFO File is inactive: /var/log/mesocollection/20170731/RepositorySettingsHelper_10.log. Closing because close_inactive of 5m0s reached.
2017/07/31 02:57:32.836147 log.go:116: INFO File is inactive: /var/log/mesocollection/20170731/MC_Entry_10.log. Closing because close_inactive of 5m0s reached.
2017/07/31 02:57:32.836248 log.go:116: INFO File is inactive: /var/log/mesocollection/20170731/MC_MainService_10.log. Closing because close_inactive of 5m0s reached.
2017/07/31 02:57:32.836211 log.go:116: INFO File is inactive: /var/log/mesocollection/20170731/MC_Return_10.log. Closing because close_inactive of 5m0s reached.
2017/07/31 02:57:45.646417 metrics.go:39: INFO Non-zero metrics in the last 30s: filebeat.harvester.closed=5 filebeat.harvester.open_files=-5 filebeat.harvester.running=-5 publish.events=5 registrar.states.update=5 registrar.writes=1

若出現以上的logs,代表filebeat有偵測到檔案的變動。

接著我們一樣透過$ curl -XPOST http://yourhost:9200/meso_sys_filelog_fb/_search?pretty=true來看看es寫入的狀況

{
  "took" : 8,
  "timed_out" : false,
  "_shards" : {
    "total" : 5,
    "successful" : 5,
    "failed" : 0
  },
  "hits" : {
    "total" : 41,
    "max_score" : 1.0,
    "hits" : [
      {
        "_index" : "meso_sys_localfile_fb",
        "_type" : "log",
        "_id" : "AV2WiYNRVf3DdKZYkE65",
        "_score" : 1.0,
        "_source" : {
          "@timestamp" : "2017-07-31T02:46:15.762Z",
          "beat" : {
            "hostname" : "6c8d38b686db",
            "name" : "6c8d38b686db",
            "version" : "5.3.0"
          },
          "input_type" : "log",
          "message" : "2017-07-31 10:46:11,021 - MC_MainService - INFO - entry log : behavior:update_system_user_rdb, data={\"$data$\": \"{\\\"firstName\\\": \\\"I-Ping\\\", \\\"email\\\": \\\"paul@meso-tek.com\\\", \\\"lastName\\\": \\\"Huang\\\"}\", \"$query$\": \"{\\\"id\\\": \\\"0e5564e8-1ac7-45db-9d0b-6f79643ca857-1501469142.056618\\\", \\\"account\\\": \\\"paul\\\"}\"}, files_count=0",
******************************************************略

若有以上的json記錄,那代表elasticsearch也可以正常的寫入了

大部分到此,kibana也不太有什麼問題了。

但問題仍是,因為log message沒有被拆解,所以我們只能把每一行當成是log message欄位來搜尋,對於報表並沒有直接幫助。

因此關於設定log message的機制,究竟只能透過logstash轉接,還是有filebeat的plugin可以用呢?這個列為本週任務來研究看看吧~

以上先記錄了filebeat最簡單的啟用與串接方式囉

 

參考:

FileBeat getting started:https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-getting-started.html

How Filebeat works:https://www.elastic.co/guide/en/beats/filebeat/current/how-filebeat-works.html

 

Docker的Hadoop一鍵啟動之旅

Docker的Hadoop一鍵啟動之旅

大數據、雲端運算這麼夯,數據資料的基礎建設是何等的重要,Hadoop基本上是個分佈式的開源應用程式框架(任意門),除了提供經典的MapReduce的平台,另外還支援分佈式的檔案系統,會說它是經典是因為現在的實務的應用程式已經都轉移到Apache Spark去了,這邊就暫且不提。

 

一般hadoop要有成效,至少要有4台主機以上….因此要建置Hadoop Distributed File System,最簡單的方式,還是透過Docker了

DockerHub上就有公司很友善的提供了Image來讓我們可以建置(試用)Hadoop(支援到Hadoop 2.7版本) …傳送門

看過Hadoop安裝於Linux的許多教學後(從java安裝到node設定,會有點想死),會萬千感謝提供這個Images的善心人士整個弄到可以一鍵安裝

 

廢話不多說,Hadoop Image Docker啟動命令:

sudo docker run -d --name=hadoop-dev-server \
	-p 8020:8020 \
	-p 8030:8030 \
	-p 8040:8040 \
	-p 8042:8042 \
	-p 8088:8088 \
	-p 19888:19888 \
	-p 49707:49707 \
	-p 50010:50010 \
	-p 50020:50020 \
	-p 50070:50070 \
	-p 50075:50075 \
	-p 50090:50090 \
	-p 9000:9000 \
	762e8eefc162 /etc/bootstrap.sh -d

建立好以後我們列表出來所有的container,發現,他已經好好的在運行了。

c93953e56bb6 762e8eefc162 “/etc/bootstrap.sh -d” 9 hours ago Up 9 hours 0.0.0.0:8020->8020/tcp, 2122/tcp, 0.0.0.0:8030->8030/tcp, 0.0.0.0:8040->8040/tcp, 0.0.0.0:8042->8042/tcp, 0.0.0.0:8088->8088/tcp, 0.0.0.0:9000->9000/tcp, 0.0.0.0:19888->19888/tcp, 0.0.0.0:49707->49707/tcp, 0.0.0.0:50010->50010/tcp, 0.0.0.0:50020->50020/tcp, 0.0.0.0:50070->50070/tcp, 0.0.0.0:50075->50075/tcp, 8031-8033/tcp, 0.0.0.0:50090->50090/tcp hadoop-dev-server

註:這個image可以讓我們一鍵啟動Single Node來試著與他的介面試著交互,然而若要實作多node的hadoop,來建立真正的分散式服務,怎麼辦?

一樣透過docker啊,多好,又有人建立了dockerfile(傳送門again),這邊先不談,先把基礎環境建立與操作方法做一篇記錄:

 

這裡面有好多port都bind出來了,但僅介紹一些常用Port,有部分Port估計是分散式架構下在用的,首先是50070,這個是Web介面,除了可以看到Hadoop Service的運行狀態,空間使用狀況,還可以看到檔案目錄清單

接著是9000,預設HDFS協定的Port,等等我們立馬來使用看看

Hadoop的檔案系統的使用方式,我知道有2種(有沒有其他方式,待後續一探究竟)

一種就是透過Web的方式,Python裡面可以安裝WebHDFS套件,透過http://xxxxx:50070,實際上是透過Restful Api進行檔案傳輸

而另一個就是直接透過hdfs協定,然而,要透過HDFS協定,就要先安裝Hadoop的程式,官網

(注意版本…目前Hadoop 2.7版本,請下載盡量相近的Hadoop版本,我就有遇到用太舊的hadoop程式去連2.7版的,出現的錯誤訊息是IPC version 9 cannot communicate with client version 4,追查了一下發現只是版本太舊的問題,透過以下下載安裝方式,就可以解決了)

這一塊因為必須具備Hdfs 的driver,所以必須要有相關的環境,像我在windows 上跑的python就因為driver問題,而選擇透過webhfds來交互

 

這次我下載的是hadoop-2.6.5 binary的版本(我之前去下載一些舊版本的hdfsclient的程式,就有遇到過不相容的狀況)

#wget http://apache.stu.edu.tw/hadoop/common/hadoop-2.6.5/hadoop-2.6.5.tar.gz

#tar -xzcf hadoop-2.6.5.tar.gz

經過一連串解壓以後,我們多了一個Hadoop 2.6.5的目錄,然而,Hadoop的程式是透過Java 寫的,所以要運行起來的話,Java 環境也是必要安裝

一種是透過手動的方式配置,詳細記錄如下:

tar -zxvf /home/paul/download/jdk-8u144-linux-x64.tar.gz -C /usr/local
mv /usr/loca/jdk-8u144-linux-x64.tar.gz /usr/local/jdk
sudo /etc/profile.d/development.sh

# 加入以下內容
JAVA_HOME=/usr/local/jdk
CLASSPATH=.:$JAVA_HOME/lib
PATH=$JAVA_HOME/bin:$PATH
export JAVA_HOME CLASSPATH PATH

# 立即生效
. /etc/profile
ln -s -f /usr/local/jdk/bin/java /usr/bin/java
ln -s -f /usr/local/jdk/bin/javac /usr/bin/javac

# 關閉selinux
sudo nano /etc/selinux/config
# 將SELINUX=enforcing改為SELINUX=disable
# 查看java版本
java -version

另一種就是透過centos的方式安裝

#sudo yum install java

#java -version

印出以下代表運行java 該有的環境已經有了

openjdk version “1.8.0_141”
OpenJDK Runtime Environment (build 1.8.0_141-b16)
OpenJDK 64-Bit Server VM (build 25.141-b16, mixed mode)

然後,我們立即對我們的容器進行hdfs連結

#cd ~/hadoop-2.6.5/bin

#./hdfs dfs -ls hdfs://localhost:9000/

註:若透過後者easy_install的方式安裝java,執行hadoop時若有出現JAVA_HOME未配置的話,就要再export JAVA_HOME=/usr/local/jdk就可以了

若有顯示檔案根目錄(理論上跟web:50070所看到的目錄結構應該要一致)

Found 3 items
drwxr-xr-x – root supergroup 0 2017-06-27 16:39 hdfs://localhost:9000/exchange
drwxr-xr-x – root supergroup 0 2017-07-26 11:28 hdfs://localhost:9000/upload_files
drwxr-xr-x – root supergroup 0 2015-07-22 23:17 hdfs://localhost:9000/user

那就代表大功告成啦啦啦啦,後續直接對這個檔案系統操作的話,再參考相關指令集教學

例如上傳檔案的話,可以透過

~/hadoop-2.6.5/bin/hdfs dfs -put ~/test.txt hdfs://localhost:9000/upload_files

不過,馬上就會面臨到權限問題:

put: Permission denied: user=paul, access=WRITE, inode=”/test.txt._COPYING_”:root:supergroup:drwxr-xr-x

web就可以直接指定root,但linux連過去會依目前的使用者作為user

因此,可以得知,只要su到root,再執行/home/paul/hadoop-2.6.5/bin/hdfs dfs -put /home/paul/test.txt hdfs://localhost:9000/upload_files就可以了

drwxr-xr-x – root supergroup 0 2017-07-26 11:50 hdfs://localhost:9000/upload_files/exchange
-rw-r–r– 3 root supergroup 5 2017-07-27 01:29 hdfs://localhost:9000/upload_files/test.txt

至於要怎麼解決這個問題,包含透過使用者有自行的目錄權限,就還需要再研究了,等明天看看吧…時候不早了..

待閱讀:hadoop權限問題參考

在centOS上安裝Docker CE(Communtity Edition) – 記錄

在centOS上安裝Docker CE(Communtity Edition) – 記錄

基本上,copy自連結,純粹記錄指令,因為各家linux的預設程式安裝器不盡相同,這邊記錄centos版本:

移除舊的docker

$ sudo yum remove docker docker-common container-selinux docker-selinux docker-engine docker-engine-selinux

設定repository(Docker CE)

  1. 安裝必要的套件 yum-utils, yum-config-manager以及devicemapper所需要的storage driver:device-mapper-persistent-data and lvm2
    sudo yum install -y yum-utils device-mapper-persistent-data lvm2
  2. 啟用the extras CentOS repository. 確保能存取到docker-c所需要的container-selinux 套件
    $ sudo yum-config-manager –enable extras
  3. 設定 預設取得stable 版本的repository(建議預設,即使你要用edge的版本)
    sudo yum-config-manager \
        --add-repo \
        https://download.docker.com/linux/centos/docker-ce.repo
  4. 選擇性: 啟用edge repository.
    $ sudo yum-config-manager –enable docker-ce-edge
  5. 若要關閉 the edge repository就使用 --disable 標籤,若要重新啟用,就使用enable標籤,以關閉為例:
    $ sudo yum-config-manager –disable docker-ce-edge

 

安裝docker

  1. 更新yum的套件清單
    $ sudo yum makecache fast
  2. 列出指定版本的docker清單
    $ yum list docker-ce.x86_64 –showduplicates |sort -r
  3. 安裝最新版本或是安裝特定版本的docker
    $ sudo yum install docker-ce
    or
    $ sudo yum install docker-ce-<VERSION>

    Warning: If you have multiple Docker repositories enabled, installing or updating without specifying a version in the yum install or yum update command will always install the highest possible version, which may not be appropriate for your stability needs.

  4. 編輯 /etc/docker/daemon.json. 好像是要配置存儲相關的設定,正式環境請見:連結{
    “storage-driver”: “devicemapper”
    }
  5. 啟動Docker.
    $ sudo systemctl start docker
  6. 可以驗證docker是否安裝正確,跑跑看docker的hello world的映象檔吧$ sudo docker run hello-world