徒然なるままに プログラミングメモや日々の生活などつれづれとつづっていくblog

2016年10月28日

Docker + PowerDNS + Sqlite + PowerDNS AdminでDNSサーバーを作る

Filed under: Docker,ESXi,OSS,オープンソース — タグ: — ranpei @ 12:00 AM

内部ツール系サーバーを構築するに当たり

内部DNSサーバーにはBindでは無くPowerDNSを使用していきます。

 

PowerDNSを使うことにしたのは単にGUIツールが存在しており

ファイルをいじって設定する手間が省けるな~とおもたっからですw

 

1.Dockerイメージを作成する

管理するドメインは大した量ではないのでDBにはSqliteをチョイス

管理GUIはSqliteに対応した物が無いため、API駆動のPowerDNS Adminを選んでみました。

PowerDNS + SqliteのDockerイメージは見つかったものの、

PowerDNS AdminのDockerイメージは見つからないし・・・・

そもそもこれぐらいならひとまとめにしてもいいじゃない!

ってことでPowerDNS + Sqliteをベースに自分で作ってみました。

[github]

PowerDNS Adminが80番ポートを使用するため、

PowerDNS標準のWebサーバーが8080番ポートに変更になっています。

また、内部運用するに当たり「DNSフォワーダ」の設定が追加されたので

管理外ドメインの問い合わせを外部にフォーワードしてくれます。

2.Dockerコンテナを起動する

$ git clone https://github.com/gittrname/powerdns-sqlite3-gui.git
$ docker build -t powerdns-sqlite3-gui powerdns-sqlite3-gui
$ docker run -p 53:53/tcp -p 53:53/udp -p 80:80 powerdns-sqlite3-gui

起動したらブラウザでGUIにアクセスしまずは管理用アカウントを新規に作成してください。

powerdnsadmin%e3%83%ad%e3%82%b0%e3%82%a4%e3%83%b3%e7%94%bb%e9%9d%a2 powerdnsadmin_%e3%82%a2%e3%82%ab%e3%82%a6%e3%83%b3%e3%83%88%e7%99%bb%e9%8c%b2

作成したアカウントでログインしたらドメインを追加しレコードの設定を行います。

powerdnsadmin_%e3%83%80%e3%83%83%e3%82%b7%e3%83%a5%e3%83%9c%e3%83%bc%e3%83%89 powerdnsadmin_%e3%83%89%e3%83%a1%e3%82%a4%e3%83%b3%e8%bf%bd%e5%8a%a0

digコマンドで動作の確認ができればDNSサーバーの構築は完了です。


$ dig www.ranran.mydns.jp @[DNSサーバーのIP]

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.ranran.mydns.jp @[DNSサーバーのIP]
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35567
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1680
;; QUESTION SECTION:
;www.ranran.mydns.jp. IN A

;; ANSWER SECTION:
www.ranran.mydns.jp. 3600 IN A [対象サーバーのIP]

;; Query time: 43 msec
;; SERVER: 192.168.11.102#53(192.168.11.102)
;; WHEN: Thu Oct 27 23:59:11 JST 2016
;; MSG SIZE rcvd: 64

2016年10月20日

既存サーバーのConcrete5データをDockerコンテナに移設する

Filed under: Concrete5,Docker,Linux,OSS,オープンソース — ranpei @ 6:09 AM

Concrete5のデータを移行していきましょう。

やり方はConcrete5公式の「concrete5 サイトを復旧(リストア)する方法」を参考にすればすんなりいきます。

 

1.移設元サーバーから移設データを取り出す

# cd /var/www/html/concrete
// データ格納フォルダをtarで固める
# tar cvf concrete-content.tar blocks/ css/ elements/ files/ helpers/ jobs/ js/ languages/ libraries/ mail/ modules/ packages/ page_types/ single_pages/ sitemap.xml themes/ tooles/ updates/
//SQLデータをエクスポート
# mysqldump -u {ユーザー名} -p {パスワード} {データベース名} >> concrete-export.sql

2.Dockerコンテナに反映させる

コンテンツファイルをDockerコンテナに反映させる。

※ コンテナ名:concrete

// SCPでファイルを移動
# cd /tmp
# scp {移設元サーバーIP}:/var/www/html/concrete/concrete-content.tar concrete-content.tar
// concreteコンテナ内にconcrete-content.tarをコピー
# docker cp concrete-content.tar concrete:/var/www/html
// tarファイルを展開
# docker exec concrete tar xvf concrete-content.tar
# docker exec concrete /bin/bash -c "chown www-data:www-data -R /var/www/html"

記事データをMySQLコンテナにインポートする。

※ コンテナ名:mysql

// SCPでファイルを移動
# cd /tmp
# scp {移設元サーバーIP}:/var/www/html/concrete/concrete-export.sql concrete-export.sql
// mysqlコンテナ内にconcrete-export.sqlをコピー
# docker cp concrete-export.sql mysql:/tmp/
// インポート
# docker exec mysql /bin/bash -c "mysql -h mysql -u {ユーザー名} -p {パスワード} {データベース名} < /tmp/concrete-export.sql"

もしかしたらディレクトリのパーミッション設定をいじる必要があるかもしれませんが・・・

ブログと違ってまだ新規のページを作成していないので何かあれば追記します。

次回、から内部ツール系サーバーの構築を行っていきます。

既存サーバーのWordPressデータをDockerコンテナへ移設する

Filed under: Docker,Linux,OSS,Wordpress,オープンソース — ranpei @ 4:27 AM

Dockerコンテナ環境の構築が完了しましたので、

既存サーバーのデータをDockerコンテナへ移設します。

※ なお、初期インストール画面での設定は終えているものとして話を進めていきます。

1.移設元サーバーから移設データを取り出す

移設するデータは記事データである”MySQLのdumpファイル”、

画像などのメディアファイルやプラグインなどが格納されている”wp-contentディレクトリ”の2つ。

// WordPress配置ディレクトリに移動 (各々のサーバー環境に合わせて読みかえてください)
# cd /var/www/html/wordpress
// wp-contentフォルダをtarで固める
# tar cvf wp-content.tar wp-content
// SQLデータをエクスポート
# mysqldump -u {ユーザー名} -p {パスワード} {データベース名} >> wordpress-export.sql

2.Dockerコンテナに反映させる

wp-contentディレクトリをDockerコンテナに配置する

※ Dockerコンテナ名:wordpress

// SCPでファイルを移動
# cd /tmp
# scp {移設元サーバーIP}:/var/www/html/wordpress/wp-content.tar wp-content.tar
// wordpressコンテナ内にwp-content.tarをコピー
# docker cp wp-content.tar wordpress:/var/www/html
// tarファイルを展開
# docker exec wordpress tar xvf wp-content.tar
# docker exec wordpress /bin/bash -c "chown www-data:www-data -R /var/www/html/wp-content"
// ディレクトリのパーミッションを変更
# docker exec wordpress /bin/bash -c "chmod 777 -R /var/www/html/wp-content/cache && chmod 777 -R /var/www/html/wp-content/uploads"

記事データをMySQLコンテナにインポートする。

※ Dockerコンテナ名:mysql

// SCPでファイルを移動
# cd /tmp
# scp {移設元サーバーIP}:/var/www/html/wordpress/wordpress-export.sql wordpress-export.sql
// mysqlコンテナ内にwordpress-export.sqlをコピー
# docker cp wordpress-export.sql mysql:/tmp/
// インポート
# docker exec mysql /bin/bash -c "mysql -h mysql -u {ユーザー名} -p {パスワード} {データベース名} < /tmp/wordpress-export.sql"

で、ブラウザでアクセスするときちんとデータが反映されていたので

これで、移設完了・・・・・と思っていたらブログの記事を書いているときに

画像をアップロードできない問題が発生しまして・・・・・

調べたところ今回の移設でwordpressの配置パスが変わったため

それに合わせて「メディア設定」>「アップロードするファイルの保存場所」のパス設定を

変更する必要がありましたのでメモしておきます。

アップロードパスの変更

 

これでWordpressデータの移設が完了しました。

2016年10月9日

Nginxをゲートウェイとした構成を構築する。

Filed under: apache,Concrete5,Docker,OSS,Roundcube,Wordpress — ranpei @ 12:43 AM

Nginxをゲートウェイにして「Concrete5」「Wordpress」「Roundcube」を構築していきます。

1.docker-compose.ymlを作ってみる

version: '2'
services:
  ######################
  # gateway-proxy
  ######################
  gateway-proxy:
    image: nginx
    container_name: gateway-proxy
    ports:
      - "80:80"
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock
      - ${PWD}/gateway_proxy/conf.d:/etc/nginx/conf.d
      - ${PWD}/gateway_proxy/htdocss/index.html:/usr/share/nginx/html/index.html
    links:
      - concrete
      - wordpress
      - roundcube
    environment:
      - NGINX_HOST={ホストのドメイン}
  #####################
  # concrete
  #####################
  concrete:
    build: concrete56-ja
    container_name: concrete
    links:
      - mysql
  #####################
  # wordpress
  #####################
  wordpress:
    image: wordpress
    container_name: wordpress
    links:
      - mysql
    environment:
      - WORDPRESS_DB_HOST=mysql:3306
      - WORDPRESS_DB_NAME=blog
      - WORDPRESS_DB_USER=blog
      - WORDPRESS_DB_PASSWORD=blog
  #####################
  # roundcube
  #####################
  roundcube:
    image: robbertkl/roundcube
    container_name: roundcube
    environment:
       - ROUNDCUBE_DEFAULT_HOST={IMAPサーバーIP or ドメイン}
       - ROUNDCUBE_DEFAULT_PORT=143
       - ROUNDCUBE_SMTP_SERVER={SMTPサーバーIP or ドメイン}
       - ROUNDCUBE_SMTP_PORT=25
       - ROUNDCUBE_SMTP_USER=%u
       - ROUNDCUBE_SMTP_PASS=%p
  #####################
  # mysql
  #####################
  mysql:
    image: mysql/mysql-server
    container_name: mysql
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock
      - mysqldata:/var/lib/mysql
      - ${PWD}/mysql/initdb.d:/docker-entrypoint-initdb.d
    environment:
      - MYSQL_ROOT_PASSWORD={MySQLルートパスワード}
      - MYSQL_ALLOW_EMPTY_PASSWORD=true

volumes:
  mysqldata:
    driver: local

/etc/nginx/conf.dをDockerホストからマウントするようにして
ホスト上のファイルを修正することで変更を容易にするようにしています。

ファイルの配置と設定は以下

作業Root/
  ├ docker-compose.yml
  |
  ├ /gateway_proxy
  |   ├ config.d/
  |   |  └ example.com.conf
  |   └ htdocss
  |      └ index.html
  |
  ├ concrete56-ja/
  |   └ Dockerfile
  |
  └ mysql/
      └ initdb.d/
          └ create_database.sql

・example.com.conf

server {
      listen 80 default_server;
      server_name example.com;

      client_max_body_size 512M;

      #
      # Log
      #
      access_log /var/log/nginx/example.com_access.log;
      error_log  /var/log/nginx/example.com_error.log;

      #
      # Header
      #
      #proxy_set_header Host $http_host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_set_header X-Forwarded-Host $http_host;
      proxy_set_header X-Forwarded-Server $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_read_timeout 600s;
      proxy_connect_timeout 10s;

      #
      # Setting
      #
      #############################
      # Nginxドキュメントルート
      #############################
      location / {
            root /usr/share/nginx/html;
            index index.html;
      }
      #############################
      # Concrete5
      #############################
      location /concrete/ {
            proxy_set_header Host $host;
            proxy_pass http://concrete/;
            proxy_redirect http://concrete/ http://$host/;
            proxy_redirect default;
      }
      #############################
      # WordPress
      #############################
      location /blog/ {
            proxy_set_header Host $host;
            proxy_pass http://wordpress/;
            proxy_redirect http://wordpress/ http://$host/;
            proxy_redirect default;
      }
      #############################
      # Roundcube
      #############################
      location /webmail/ {
            proxy_cookie_path /webmail/ /;
            proxy_pass http://roundcube/;
            proxy_redirect / /webmail/;
            proxy_redirect default;
      }
}

・index.html
~省略~

・create_database.sql

-- WordPress
CREATE DATABASE IF NOT EXISTS blog CHARACTER SET utf8;
GRANT all ON concrete.* TO 'blog'@'%' identified by 'blog';
-- Concrete5
CREATE DATABASE IF NOT EXISTS concrete CHARACTER SET utf8;
GRANT all ON concrete.* TO 'concrete'@'%' identified by 'concrete';

buildすれば各コンテナが配置されます。


$docker-compose up -d

で、起動するわけなんですが
ブラウザでアクセスしてみるとこんな感じに・・・・

alias%e8%a8%ad%e5%ae%9a%e5%89%8d_concrete5 alias%e8%a8%ad%e5%ae%9a%e5%89%8d_wordpressalias%e8%a8%ad%e5%ae%9a%e5%89%8d_roundcube

 

※ 左から「Concrete5」「Wordpress」「Roundcube」です。

Roundcube以外がうまく行ってませんね。。。。

 

 

 

2.問題へ対応する

調べてみたところ”/blog/”を”/”にリバースしているため「Concrete5」「Wordpress」は”/”にアクセスが来たと解釈しURL生成していました。

そのためリダイレクト先やCSS、JSのURLが正確なパスではないためブラウザからはアクセスできなくなってしまっているわけです。

で、結局どうしたかというと・・・・・・・

「Concrete5」「Wordpress」のApacheに強引にAliasを切って対応しましたwww

いやね、Proxyの設定見直せばいけるかなと思ったんですが

調べれば調べるほど全然ダメみたいで・・・

結局、最終構成は以下となりました。

version: '2'
services:
  ######################
  # gateway-proxy
  ######################
  gateway-proxy:
    image: nginx
    container_name: gateway-proxy
    ports:
      - "80:80"
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock
      - ${PWD}/gateway_proxy/conf.d:/etc/nginx/conf.d
      - ${PWD}/gateway_proxy/htdocss/index.html:/usr/share/nginx/html/index.html
    links:
      - concrete
      - wordpress
      - roundcube
    environment:
      - NGINX_HOST={ホストのドメイン}
  #####################
  # concrete
  #####################
  concrete:
    build: concrete56-ja
    container_name: concrete
    volumes:
      - ${PWD}/concrete/concrete-alias.conf:/etc/apache2/sites-enabled/concrete-alias.conf
    links:
      - mysql
  #####################
  # wordpress
  #####################
  wordpress:
    image: wordpress
    container_name: wordpress
    volumes:
      - ${PWD}/wordpress/wordpress-alias.conf:/etc/apache2/sites-enabled/wordpress-alias.conf
    links:
      - mysql
    environment:
      - WORDPRESS_DB_HOST=mysql:3306
      - WORDPRESS_DB_NAME=blog
      - WORDPRESS_DB_USER=blog
      - WORDPRESS_DB_PASSWORD=blog
  #####################
  # roundcube
  #####################
  roundcube:
    image: robbertkl/roundcube
    container_name: roundcube
    environment:
       - ROUNDCUBE_DEFAULT_HOST={IMAPサーバーIP or ドメイン}
       - ROUNDCUBE_DEFAULT_PORT=143
       - ROUNDCUBE_SMTP_SERVER={SMTPサーバーIP or ドメイン}
       - ROUNDCUBE_SMTP_PORT=25
       - ROUNDCUBE_SMTP_USER=%u
       - ROUNDCUBE_SMTP_PASS=%p
  #####################
  # mysql
  #####################
  mysql:
    image: mysql/mysql-server
    container_name: mysql
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock
      - mysqldata:/var/lib/mysql
      - ${PWD}/mysql/initdb.d:/docker-entrypoint-initdb.d
    environment:
      - MYSQL_ROOT_PASSWORD={MySQLルートパスワード}
      - MYSQL_ALLOW_EMPTY_PASSWORD=true

volumes:
  mysqldata:
    driver: local

 

・ファイル配置
作業Root/
  ├ docker-compose.yml
  |
  ├ /gateway_proxy
  |   ├ config.d/
  |   |  └ example.com.conf
  |   └ htdocss
  |      └ index.html
  |
  ├ wordpress/
  |   └ wordpress-alias.conf
  |
  ├ concrete56-ja/
  |   ├ Dockerfile
  |   └ concrete-alias.conf
  |
  └ mysql/
      └ initdb.d/
          └ create_database.sql

・example.com.conf

server {
      listen 80 default_server;
      server_name example.com;

      client_max_body_size 512M;

      #
      # Log
      #
      access_log /var/log/nginx/example.com_access.log;
      error_log  /var/log/nginx/example.com_error.log;

      #
      # Header
      #
      #proxy_set_header Host $http_host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_set_header X-Forwarded-Host $http_host;
      proxy_set_header X-Forwarded-Server $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_read_timeout 600s;
      proxy_connect_timeout 10s;

      #
      # Setting
      #
      #############################
      # Nginxドキュメントルート
      #############################
      location / {
            root /usr/share/nginx/html;
            index index.html;
      }
      #############################
      # Concrete5
      #############################
      location /concrete/ {
            proxy_set_header Host $host;
            proxy_pass http://concrete/concrete/;
            proxy_redirect http://concrete/ http://$host/;
            proxy_redirect default;
      }
      #############################
      # WordPress
      #############################
      location /blog/ {
            proxy_set_header Host $host;
            proxy_pass http://wordpress/blog/;
            proxy_redirect http://wordpress/ http://$host/;
            proxy_redirect default;
      }
      #############################
      # Roundcube
      #############################
      location /webmail/ {
            proxy_cookie_path /webmail/ /;
            proxy_pass http://roundcube/;
            proxy_redirect / /webmail/;
            proxy_redirect default;
      }
}

・concrete-alias.conf

alias /concrete /var/www/html

・wordpress-alias.conf

alias /wordpress/var/www/html

・index.html
~省略~

・create_database.sql

-- WordPress
CREATE DATABASE IF NOT EXISTS blog CHARACTER SET utf8;
GRANT all ON concrete.* TO 'blog'@'%' identified by 'blog';
-- Concrete5
CREATE DATABASE IF NOT EXISTS concrete CHARACTER SET utf8;
GRANT all ON concrete.* TO 'concrete'@'%' identified by 'concrete';

volumeがファイル単体もマウントできるんでできた荒業ですw

完全にバッドノウハウですよね・・・・

まあ、今後の課題ですかな・・・

2016年10月6日

Concrete5.6 日本語版用のDockerfileを作る

Filed under: Concrete5,Docker,Linux,OSS,オープンソース,PC — ranpei @ 11:51 PM

Dockerのインストールが終わってしまえば後はDocker Hubから

使いたいDockerイメージを持ってきてコンテナを作成するだけなのですが・・・・

Concrete5のコンテナを作成するときに問題があったため少しメモを。。。

 

1.発覚した問題

Concrete5の移行手順を調べているときに分かったのですが・・・

最新の5.7では下位互換がなくなっていたのです!!

今運用しているのは5.6・・・これじゃ移行できないよ・・・・・

5.6を探すもなかなか見つからず・・

さらにDocker Hub上のconcrete5のイメージは大半が本家のソースをDLして作られているために

運よく5.6のイメージが見つかっても日本語表示に不安が・・・・

 

2.だったら作ればいいじゃない!

そんなわけで、Concrete5のイメージは自分で作成することにしました。

で、作成したDockerfileが以下

FROM chriswayg/apache-php

RUN apt-get update && \
    apt-get install -y wget unzip php5-mysql php5-gd && \
    apt-get clean && \
    apt-get -yq autoremove && \
    rm -rf /var/lib/apt/lists/*

RUN cd /tmp && \
    wget -O concrete.zip http://concrete5-japan.org/index.php/download_file/view/1920/45/ && \
    unzip concrete.zip && \
    rm /tmp/concrete.zip && \
    cp -rp /tmp/concrete5.6.3.4.ja/* /var/www/html && \
    chown www-data:www-data -R /var/www/html && \
    chmod 777 -R /var/www/html/config && \
    chmod 777 -R /var/www/html/files && \
    chmod 777 -R /var/www/html/packages && \
    chmod 777 -R /var/www/html/themes && \
    chmod 777 -R /var/www/html/updates && \
    rm -rf /var/www/html/index.html

RUN echo php_value default_charset UTF-8 >> /var/www/html/.htaccess && \
    echo php_value mbstring.language neutral >> /var/www/html/.htaccess && \
    echo php_value mbstring.internal_encoding UTF-8 >> /var/www/html/.htaccess && \
    echo php_flag mbstring.encoding_translation Off >> /var/www/html/.htaccess

EXPOSE 80 443

GitHub⇒gittrname/concrete56-ja

バージョン番号などがファイルに含まれる場合は、

バージョンアップ時に変わることを考慮した作りにするのですが今回は考慮していません。

(5.6がバージョンアップされることはそうそう無いでしょう)

このDockerfileをbuildすることでイメージが作成されます。

 

3.docker-composeで一括作成

最後に自前のDockerfileと公式のMySQLイメージを使って

Concrete5のコンテナ環境を作成していきましょう。

  • フォルダの構成

以下のようにファイルを配置します。

作業Root/
  ├ docker-compose.yml
  ├ concrete56-ja/
  |   └ Dockerfile
  └ mysql/
      └ initdb.d/
          └ create_concrete_database.sql
  • docker-compose.ymlの中身
version: '2'
services:
  #####################
  # concrete5.6-ja
  #####################
  concrete:
    build: concrete56-ja
    container_name: concrete
    links:
      - mysql
  #####################
  # mysql
  #####################
  mysql:
    image: mysql/mysql-server
    container_name: mysql
    volumes:
      - mysqldata:/var/lib/mysql
      - ${PWD}/mysql/initdb.d:/docker-entrypoint-initdb.d
    environment:
      - MYSQL_ROOT_PASSWORD={rootユーザーのパスワード}
volumes:
  mysqldata:
    driver: local

MySQL公式コンテナはdocker-entrypoint-initdb.d配下のSQLやシェルスクリプトをコンテナ作成時に実行するので
それを利用し初期DBと接続用ユーザーの作成を行っています。

SQLはこんな感じ

-- Concrete
CREATE DATABASE IF NOT EXISTS concrete CHARACTER SET utf8;
GRANT all ON concrete.* TO 'concrete'@'%' identified by 'concrete';

 

linksでMySQLコンテナを指定していますので、

IPアドレスを調べなくてもコンテナ名を使ってDockerコンテナ間の通信が可能になっています。

あとは、docker-compose.ymlファイルがある階層で

docker-composeを起動するだけでビルドからコンテナ作成まで一通りやってくれます。


// コンテナ起動

$ docker-compose up -d

// 起動確認

$ docker ps -a

 

作成が終わったら公式のインストール手順に従ってブラウザから初期設定を行うだけです。

2016年10月5日

CentOS 7.2でDocker環境構築

Filed under: Docker,ESXi,Linux,OSS,PC — ranpei @ 9:22 PM

内部ツール系サーバーは CentOS 7.2を使って構築していきます。

外部と別ディストリビューションを使うのに特に理由はありません。

単に私がいろいろなディストリビューションを触りたいというだけですw

 

 

1.Dockerをインストール

// Dockerをインストール
#yum -y install docker
// サービスを起動
#systemctl start docker
#systemctl enable docker
// 動作確認
#docker run hello-world

2.Docker-Composeのインストール(最新版はここを参照)

こちらにもDocker-Composeをインストールしておきます。

#curl -L https://github.com/docker/compose/releases/download/1.8.1/docker-compose-`uname -s`-`uname -m` > docker-compose
#chmod +x docker-compose
#sudo mv ./docker-compose /usr/local/bin/docker-compose

あとselinuxが有効な状態だとマウントしたvolumeに書き込むことができないので
selinuxを無効化しておきます。

#vi /etc/selinux/config
SELINUX=enforcing
 ↓
SELINUX=disabled

再起動すれば設定が反映されます。
こちらもすんなりいきましたね。

Ubuntu 16.04でDocker環境構築

Filed under: Docker,ESXi,Linux,OSS,PC — ranpei @ 9:22 PM

外部公開ツール系サーバーはUbuntu Server 16.04 LTSで作成し、

複数コンテナの管理をやりやすくするためにDocker-Composeをインストールします。

※ Ubuntuのインストールは省略

1.Dockerのインストール (ここを参照)

// 最新パッケージをインストール
$sudo curl -fsSL https://get.docker.com/ | sh
// 一般ユーザに"docker"グループの追加
$sudo gpasswd -a {ユーザー名} docker
// ログアウト
$exit

再度ログインして以降の手順を実施

// Dockerサービスを起動
$sudo service docker start
// 動作確認
$docker run hello-world

2.Docker-Composeのインストール(最新版はここを参照)

$curl -L https://github.com/docker/compose/releases/download/1.8.1/docker-compose-`uname -s`-`uname -m` > docker-compose
$chmod +x docker-compose
$sudo mv ./docker-compose /usr/local/bin/docker-compose

自宅サーバーをDockerで再構築する

Filed under: Docker,ESXi,GitLab,Linux,OSS,PC — ranpei @ 3:08 AM

なかなか長続きしないものですね。。。

まあだらだら日記を書くよりもできるだけ有益な情報のみを書く方針なので

ネタがなかったってだけなんですがね・・・・

 

さて、今回は自宅サーバーをDockerを使って再構築した話を複数回にわたって書いて行こうと思います。

(後ろの方はDocker要素ほとんどないかと思いますがw)

 

1.Dockerで再構築しようと思った訳

Linuxのお試し用にVMを作ろうと思ったらメモリ残量がほとんどないことに気が付きまして・・・

サーバーリソース量

稼働中のVMを調べてみたところ各VMに設定しているメモリ量の合計が搭載メモリ量カツカツな状態でしたw

にもかかわらずVM内部では確保したメモリは半分も使用されていないという状況・・・

各VMのメモリ使用量

Dockerを使えば確保するメモリ量を減らし、なおかつサーバーリソースを有効に利用できるのでは?

と思い立ったのがきっかけです。

 

2.サーバー構成を考えてみる

現在実運用中のサーバーは以下の図のようになっています。

現行サーバー構成図

  • ゲートウェイサーバー
    • インターネットからの入口に置かれ内部サーバーとの中継役を担うサーバー
    • Webサイト高速化のためにキャッシュ役も担う
  • アプリケーションサーバー
    • 実際のアプリ運用を担当するサーバー
    • ブログやCMSなど様々なアプリが同居している
  • データベースサーバー
    • 文字通りデータベースサーバー
  • Gitlab運用サーバー
    • GitlabやJenkinsなど開発サポート用のツール類を運用するサーバー
    • 内部利用が主のため基本的に外部に解放しない
  • メールサーバー
    • プライベートメールアドレスなどの運用を行うサーバー
    • アプリ運用中の通知メールなどを外部に送信する際に使用される

 

これをDockerを使って以下のように2台のVM内に集約してしまおうと画策してみました。

想定サーバー構成図

  1. ゲートウェイサーバー、アプリケーションサーバー、データベースサーバー、メールサーバーを集約
  2. 1アプリを1コンテナとして、蓄積データは個別のデータコンテナに保存することで永続化

が!しかし!?

結局想定通りにはいかず・・・・

以下の図のようになりました。

最終サーバー構成図

  1. メールサーバー、VPNサーバーはDocker化できず仕方なく通常のVMのまま運用・・・
  2. データコンテナはアプリによって保存がうまくいかないためデータボリューム方式に妥協・・
  3. 図では分かりにくいですがGitlabは永続化すらできていませんw

 

3.想定通りにいかなかった理由

自身のDockerへの理解不足などもあったためですが、個別にうまくいかなかった分けをつらづらと・・・・

  • メールサーバー

Linuxユーザーを作成して、各自の個人ディレクトリにメールを保存するという現状運用がDockerにミスマッチでした。

特に複数のユーザーアカウントをどのように永続化するか課題となり移行を断念。

おそらくですが複数ユーザーで運用する場合はユーザーアカウントはLDAPなどで一元管理して、

バーチャルメールボックス方式での運用となるのではないでしょうか?

  • VPNサーバー

構成自体はfrosquin/softetherを使って簡単に構築できたのですが、以下の2つの問題が発生。

1.DockerホストのVMにsshでログインできない

2.DockerホストのOSが64bitだったため「Softether VPN 経由でVMware vSphere Clientが開かない」の内容が再発してしまった

そのためリモート管理に支障を期すのでDocker化は断念し、

Dockerホストの環境を汚さないように別建てでVPN専用サーバーを建てるにしました。

  • Gitlab

PostgreSQLやWebサーバー等が1コンテナにまとまった物を使ったためコンテナ内で複数のデーモンが読み書きを行っており

DockerのVolumeのアクセス権限の問題について」の問題がネックとなって永続化は断念しました。

データの保全はGitlabのバックアップ機能を使って定期的にバックアップ作成し、Dockerホストにコピーして対応しています。

(今回、私は横着して1つにまとまった物を使用しましたが

Gitlabを運用する場合はデータベースサーバーやWebサーバーなどを個別に建てるのが正解だと思います)

 

4.最後に

一応移行自体は終わって1.5GBほどののメモリを確保できましたが、

今後のことを考えるとVPNサーバーはともかく、

Gitlabはバックアップでは心もとないためデータの永続化は必須ですし、

NASや各アプリのアカウント管理も地味に面倒なので、LDAP等で一元管理するようにして

メールサーバーの再構築ぐらいは行いたいですね。。。

では、実際の構築作業等は別記事で!!

2015年9月30日

PHPフレームワーク公開

Filed under: PHP,オープンソース,ソース配布 — ranpei @ 3:40 AM

仕事でPHPフレームワークを使ったときに以下の不満点がふつふつと湧き上がってきた。

・クラス名やメソッド名がURIパスになってしまう。

・各ファイルの配置先があらかじめ決められており自由度がない。

・内蔵ライブラリは便利だが外部ライブラリにもっと良いものがあるのに導入に手間がかかる。

 

上記の一部の不満点はメンバーから上がってきたもので

そのときはクラス名とメソッド名の変更で対応したもののもっとうまいやり方があったのでは?と思っていた。

 

もともとPHPは趣味でやっておりオレオレフレームワークで実装することが主だったため

既存フレームワークの良いところを取り入れつつ上記の不満点を解消できないかと試行錯誤していたものが形になったため

せっかくだから公開してみようとということになった。

 

ダウンロードから設置までの流れはこちらにまとめている。(内容が薄いため今後拡充していく予定)

 

現状ではフレームワークの骨組みはどのように作られているかという勉強用のソースという意味合いが強い。

最終的には小規模なシステム開発に向いたフレームワークとしていきたい。

(さすがに中大規模は無理なのでメジャーなPHPフレームワークを使用していただきたい。)

 

あと、ソース類はgithubなどのサービスを利用して配布していければ良いなーとか考えていたり・・・

2014年10月15日

不正アクセス再び

Filed under: postfix,ログ,不正アクセス — ranpei @ 12:20 AM

以前Webサーバーを踏み台にされた話をしましたが。

今度はMailサーバーを踏み台にされてしまいました;x;

 

 

ことの発端は以下のメールが送られてきたことでした。
————————————————————————————————
警告:お客様サーバーからのフィッシングメール送信行為について

いつもMyDNS.JPをご利用頂きましてありがとうございます。

お客様が使用している回線から、フィッシングメールがMyDNS.JPのメール
リレーサーバー経由で送信されていることを確認いたしました。

このような行為は、社会的に非常に迷惑であり、加入規約に反しており
ますので行なわないようにして頂けますようお願い致します。

再度行なわれた場合には、以後の利用を禁止させて頂きます。

もし身に覚えがないようであれば、お客様のサーバーがクラッキングを
受けていないかどうか確認をしていただけますようお願いいたします。

また、本件についてお客様のアクセス状況や個人情報を関係省庁に報告
することもありますので予めご了承ください。
————————————————————————————————

 

昼間はとりあえずスマホからVPNでメールサーバーを停止して、これ以上のスパム送信を防ぐ暫定措置をとり。

帰宅後にぐぬぬ、postfixで踏み台にされたお話を参考にログを解析しました。

以下が実際のログの一部です。

Sep 14 15:36:25 localhost postfix/smtpd[28698]: connect from unknown[216.251.77.186]
Sep 14 15:36:27 localhost postfix/smtpd[28698]: 06A9780053: client=unknown[216.251.77.186], sasl_method=LOGIN, sasl_username=○○○○@mail.ranran.mydns.jp
Sep 14 15:36:28 localhost postfix/cleanup[29044]: 06A9780053: message-id=<>
Sep 14 15:36:28 localhost postfix/qmgr[1936]: 06A9780053: from=<info@rolandbest.com>, size=1949, nrcpt=5 (queue active)
Sep 14 15:36:28 localhost postfix/smtpd[28698]: disconnect from unknown[216.251.77.186]
Sep 14 15:36:29 localhost postfix/smtp[29045]: 06A9780053: to=<tunde.adeoye@aol.com>, relay=auth.gate-on.net[210.197.72.170]:587, delay=2.9, delays=1.7/0.02/0.1/1.1, dsn=2.0.0, status=sent (250 Ok: queued as 8C61DD73A9)
Sep 14 15:36:29 localhost postfix/smtp[29045]: 06A9780053: to=<gordonbank11@gmail.com>, relay=auth.gate-on.net[210.197.72.170]:587, delay=2.9, delays=1.7/0.02/0.1/1.1, dsn=2.0.0, status=sent (250 Ok: queued as 8C61DD73A9)
Sep 14 15:36:29 localhost postfix/smtp[29045]: 06A9780053: to=<adamfarm103@hotmail.com>, relay=auth.gate-on.net[210.197.72.170]:587, delay=2.9, delays=1.7/0.02/0.1/1.1, dsn=2.0.0, status=sent (250 Ok: queued as 8C61DD73A9)
Sep 14 15:36:29 localhost postfix/smtp[29045]: 06A9780053: to=<honare.ravzio@ig.com.br>, relay=auth.gate-on.net[210.197.72.170]:587, delay=2.9, delays=1.7/0.02/0.1/1.1, dsn=2.0.0, status=sent (250 Ok: queued as 8C61DD73A9)
Sep 14 15:36:29 localhost postfix/smtp[29045]: 06A9780053: to=<a4deoye2004@yahoo.com>, relay=auth.gate-on.net[210.197.72.170]:587, delay=2.9, delays=1.7/0.02/0.1/1.1, dsn=2.0.0, status=sent (250 Ok: queued as 8C61DD73A9)
Sep 14 15:36:29 localhost postfix/qmgr[1936]: 06A9780053: removed

アカウントは伏せていますが、あるアカウントがハックされて1秒ごとに3~5通のペースでメールを送信していました。

(1週間余りでログが2Gぐらいになっていた)

参考にした「online106の日記」と同じで特定のアカウントをのっとってメールを不正に送信されていたようです。

 

とりあえず該当のアカウントのパスワードを変更して、様子を見ています。

今のところ、すべて認証エラーとなっていますが、先々のことを考えるとセキュリティを強化する必要がありそうです。

幸いにも「online106の日記」さんの中でそのことについても触れられているので、参考にして実施することにします。

とりあえず今日はここまで。

« Newer PostsOlder Posts »

Powered by WordPress