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

2022年1月2日

K3osでk3s環境を構築してみる。

Filed under: k3os,k3s,k8s,Kubernetes,Linux,OSS — ranpei @ 8:28 PM

k8s環境としてUbuntu + microk8sを使っていましたがリソース消費が多いのがたまに傷。

おまけにk8sの機能もそれほど使っていないこともあり、k3s環境に乗り換えることにしました。

k3osで構築したのですがその時の構築メモを残します。

◆k3osのインストール

isoイメージでlive起動したらrancher/<パスワードなし>でログインし、以下のコマンドでインストールを開始します。

$ sudo k3os install

各種設定はこちらのサイトを参考にしました。

再起動後、パスワード認証でSSH接続できるように設定を変更します。

$ sudo vi /etc/ssh/sshd_config
// コメントアウト箇所を修正
#PasswordAuthentication no
PasswordAuthentication yes
// サービスを再起動
$ sudo service sshd restart

◆k3osのネットワーク設定

初期状態ではDHCP接続になっているので固定IPに変更します。

// ネットワークデバイスを表示
$ sudo connmanctl services
// ネットワークデバイスの情報を表示
$ sudo connmanctl service ethernet_xxxxxxx_cable
// IPv4アドレスを設定
$ sudo connmanctl config ethernet_xxxxxxx_cable --ipv4 manual 192.168.xx.xx 255.255.255.0 192.168.xx.xx --nameservers 192.168.xx.xx
// ネットワークを再起動
$ sudo service connman restart

再起動後、sshクライアントでrancher/<インストール時に設定したパスワード>でログインできるか試してみましょう。

◆各種設定をcloud-initで設定

我が家ではプライベートレジストリでDockerイメージを管理しているのでその設定を追加します。

// 以下のファイルを新規作成
$ sudo vi /var/lib/rancher/k3os/config.yaml

k3os:
  ntp_servers:
    - ntp.nict.jp
write_files:
- content: |
    mirrors:
      docker.io:
        endpoint:
          - "https://registry.gitlab.com"
      "192.168.xx.xx:5000":
        endpoint:
          - "http://192.168.xx.xx:5000"
  owner: root
  path: /etc/rancher/k3s/registries.yaml
  permissions: '0755'
hostname: k3os-server

// システムを再起動
$ sudo reboot

なお、NTPの設定をしないとなぜかkubectlコマンドが証明書の期限切れで受付られなかったため設定しています。

これでk3s環境は構築できました。

2018年8月20日

GoAccessを使ってリアルタイムアクセス解析を行う

Filed under: GoAccess,Linux,Nginx,OSS,ログ,不正アクセス — ranpei @ 9:04 PM

Ubuntu 16.04 + Nginx にGoAccessを使ったリアルアイムアクセス解析の環境を作ったのでその内容をメモ。

 

1.GoAccessをインストール
これは公式の手順を参考にインストール。

// 必要パッケージをインストール
$ sudo apt-get -y install libncursesw5-dev gcc make
$ sudo apt-get -y install libgeoip-dev libtokyocabinet-dev

// GoAccessをダウンロード
$ wget http://tar.goaccess.io/goaccess-1.2.tar.gz

// コンパイルしてインストール
$ tar -xzvf goaccess-1.2.tar.gz
$ cd goaccess-1.2
$ sudo ./configure --enable-utf8 --enable-geoip=legacy
$ sudo make
$ sudo make install
$ sudo ln -s /usr/local/bin/goaccess /usr/bin/goaccess

インストールできたら試しに解析してみる。

$ sudo goaccess /var/log/nginx/access.log --log-format=COMBINED

こんな画面が表示される。

 

さて、GoAccessは解析結果をHTMLとして出力することもでき、
さらに –real-time-html オプションをつけることで常時情報が更新されるHTMLを出力できます。

注意点としては情報更新の通信(WebSocket)に 7890番ポートを使用するためFWを開放しておきましょう。

$ sudo ufw allow 7890

※ ルーターの開放なども必要ですが割愛します。

開放したら以下のコマンドでリアルタイム解析HTMLを出力しましょう。

$ sudo goaccess /var/log/nginx/access.log -a -o /usr/share/nginx/html/report.html --real-time-html --log-format=COMBINED

http://[ホスト名 or IPアドレス]/report.html にアクセスすると以下ような画面が見れるはずです。

 

 

2.サービス化する
常時起動するには毎回先ほどのコマンドを実行するわけにはいきませんので、

今回はサービス化して常時起動する状態にしたいと思います。

// 定義ファイルを作成
$ sudo vi /etc/systemd/system/goaccess.service
↓↓ 記載
[Unit]
Description=Goaccess Web log report.
After=network.target

[Service]
Type=simple
User=root
Group=root
Restart=always
ExecStart=/usr/local/bin/goaccess -a -g -f /var/log/nginx/access.log -o /usr/share/nginx/html/report.html --real-time-html --log-format=COMBINED --ws-url <host名>
StandardOutput=null
StandardError=null

[Install]
WantedBy=multi-user.target
↑↑ 記載

// サービスファイルとして認識されたか確認
$ sudo systemctl list-unit-files --type=service | grep goaccess
goaccess.service disabled ← 表示されればOK

// サービスを有効化
$ sudo systemctl enable goaccess

// サービス起動
$ sudo systemctl start goaccess

// サービス状態確認
$ sudo systemctl status goaccess
● goaccess.service - Goaccess Web log report.
Loaded: loaded (/etc/systemd/system/goaccess.service; enabled; vendor preset: enabled)
Active: active (running) since 月 2018-08-20 16:46:27 JST; 4h 5min ago
Main PID: 91584 (goaccess)
Tasks: 3
Memory: 3.7M
CPU: 1min 7.536s
CGroup: /system.slice/goaccess.service
mq91584 /usr/local/bin/goaccess -a -g -f /var/log/nginx/access.log -o /usr/share/nginx/html/report.html -

8月 20 16:46:27 MainServer systemd[1]: Started Goaccess Web log report..

起動できたら先ほどのURLにアクセスしてみましょう
きちんと解析画面が表示されれば設定完了です。

 

あとは必要であればアクセス制限を設けるなどしてください。

2018年4月22日

1つのサーバーでMastodonとPleromaを運用すると相互にフォローできない件

Filed under: Docker,Mastodon,OSS,オープンソース — ranpei @ 8:31 PM

うちの鯖ではDockerで構築したMastodonとPleromaとMisskeyの各インスタンスをVirtualHostでドメインごとに振り分ける運用をしています。

 

ただ、外部のインスタンスとはフォローし合えるのに内部のインスタンス同士ではフォローできずに困っておりました。

 

で、原因を探ったら以下の手順を踏むことで回避できました。

■回避方法

  1. DNSやhostsを使って名前解決できるようにする。
  2. Mastodonのソースをいじる。

 

順に説明していきます。

 

1.DNSやhostsを使って名前解決できるようにする。

まあ、これは真っ先に疑うことですよね^^;

LAN内部からドメインでアクセスするためには内部DNSを構築するかhostsを書き換えなければいけません。

うちは内部DNSを構築済みだったためこいつに設定を追加するだけで済みました。

そして、相互に名前解決できるようになったのですがこれだけでは不十分という・・・・

(一応Mastodonの検索欄で”@名前@ドメイン”で検索した際のエラーが「503 Remote data could not be fetched」→「422 Mastodon::HostValidationError on ドメイン」と変化しました)

 

 

2.Mastodonのソースをいじる。

この「422 Mastodon::HostValidationError」ってエラーについて調べてみてもよくわかんない(422ってWebDav拡張のステータスらしいですが・・・)

しょうがないのでMastodonのソースを見て「Mastodon::HostValidationError」がスローされている箇所を見てみると

app/lib/request.rb(135行目)に気になる部分を発見。

        Addrinfo.foreach(host, nil, nil, :SOCK_STREAM) do |address|
          begin
            raise Mastodon::HostValidationError if PrivateAddressCheck.private_address? IPAddr.new(address.ip_address)
            return super address.ip_address, *args
          rescue => e
            outer_e = e
          end
        end

これはプライベートアドレスの場合は問答無用にHostValidationErrorにしている??

 

で、PrivateAddressCheckについて調べてみるとconfig/environments/development.rbでわざわざfalseを返すように書き換えを行っていました。

ということはここのチェックでfalseとなるようにすればいいのでは??っと思いconfig/environments/production.rb側に以下の記載を追記。

module PrivateAddressCheck
 def self.private_address?(*)
 false
 end
end

 

そしてDockerコンテナをビルドしなおしてみると・・・・


$ docker-compose build web
$ docker-compose up -d

無事検索欄で”@名前@ドメイン”で検索してもちゃんとアカウントが表示されるようになりましたv^^v

 

 

とりあえずフォローできない問題は解決したんですが以下の2つが気になる。。。

  1. Mastodonはなぜわざわざプライベートアドレスをはじくようにしているのか?
  2. この対応の仕方で不都合が起きることはないのか?

そんなわけでこの対処方法は自己責任で行ってください。

2017年10月1日

Cakephp3.x系でSAML認証を実装する

Filed under: apache,Cakephp3,OSS,PHP,SAML認証 — ranpei @ 7:12 AM

今回は完全プライベートなネタではないのですが、

Cakephp3を使ってSAML認証を行うプラグインを作成したのでその使い方をまとめようと思います。

(SAMLの設定が結構面倒なのでまとめておきたかったってのもあります。)

 

■環境構築

何はともあれ、まずは環境構築です。

今回の構成は以下のようになります。

・基盤

OS: CentOS7.2

Webサーバー:Apache2.4

PHP: 5.6

・アプリケーション

Identity Provider: SimpleSAMLphp

Service Provider: Cakephp3.x + 自前プラグイン(SamlAuthenticationPlugin)

 

●Apacheインストール

# yum install httpd

●PHP5.6インストール

普通にyumでインストールすると5.4系が入るため、

ここを参考にEPELとRemiリポジトリのパッケージを使用します。

# yum install epel-release
# rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
# yum install --enablerepo=remi,remi-php56 php php-devel php-mbstring php-mysql php-pdo php-gd php-xml php-mcrypt php-gmp php-intl

バージョンを確認してみましょう。

# php -v
PHP 5.6.31 (cli) (built: Jul 6 2017 08:06:11)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies

 

Cakephpのパッケージ管理に使用されているためComposerをインストールします。


# curl -sS https://getcomposer.org/installer | php
# mv composer.phar /usr/local/bin/composer

 

●SimpleSAMLphp配置

SimpleSAMLphpを配置します。配置先はhttp://xxx.xxx.xxx/simplesaml/とします。

 

まずは、公式サイトからファイルを落としてきましょう。

DLし終わったらSCPなどを使ってWebサーバーにアップロードしてください。

 

●SimpleSAMLphpの設定

ファイルの解凍と配置を行います。(私は/var/www/simplesaml/に配置しました)

# tar zxvf simplesamlphp-1.14.16.tar.gz
# mv simplesamlphp-1.14.16 /var/www/simplesaml

 

●Cakephp3.x + 自前プラグイン

まずはCakephpを配置します。(私は/var/www/ssoapp/に配置しました)

# composer self-update && composer create-project --prefer-dist cakephp/app ssoapp

 

pluginsフォルダにSAML認証プラグインを配置します。

# cd ssoapp/plugins
# git clone https://github.com/gittrname/SamlAuthenticationPlugin.git

 

プラグインを有効化しましょう。

# cd ..
# vi config/bootstrap.php
// 最下部に追記
Plugin::load('SamlAuthenticationPlugin', ['bootstrap' => true, 'routes' => true]);
# vi composer.json
// 以下を編集
"josegonzalez/dotenv": "2.*"
↓
"josegonzalez/dotenv": "2.*",
"onelogin/php-saml": "^2.11.0"
&nbsp;
"psr-4": {
"App\\": "src"
}
↓
"psr-4": {
"App\\": "src",
"SamlAuthenticationPlugin\\": "plugins/SamlAuthenticationPlugin/src"
}

 

終わったらcomposerで外部ライブラリのインストールと

autoloadの構築を行います。

# composer install

 

 

●ApacheのAlias設定

# vi /etc/httpd/conf.d/saml.conf ← 新規作成
// 以下を記載
Alias /simplesaml/ /var/www/simplesaml/www/
<Directory /var/www/simplesaml/www/>
AllowOverride None
Require all granted
</Directory>

Alias /ssoapp/ /var/www/ssoapp/webroot/
<Directory /var/www/ssoapp/webroot/>
AllowOverride None
Require all granted
<IfModule mod_rewrite.c>
RewriteEngine On
# RewriteRule ^(.*)/$ /ssoapp/$1 [L,R=300]
RewriteBase /ssoapp
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [L]
</IfModule>
</Directory>

Apacheを再起動します。

# systemctl restart httpd

 

ここまででとりあえず前段階終了です。

・・・・そう!前段階なんです。この後の設定が回りくどく苦戦しました;;;

 

ざっくり行くと、まずIdpの証明書情報などをSPに登録、

次にSPの証明書情報などをIdpに登録する流れになります。

 

●Idpの証明書情報をSPに登録

登録する前にIdp側で証明書を作成します。

(実働環境だとオレオレではなく正規に発行してもらったものを使用するんでしょうね)

# cd /var/www/simplesaml/cert
# openssl req -newkey rsa:2048 -new -x509 -days 3652 -nodes -out server.crt -keyout server.pem

SAML2.0-Idpのモジュールを有効化します。

# vi /var/www/simplesaml/config/config.php
// 以下を変更
'enable.saml20-idp' => false,
↓
'enable.saml20-idp' => true,
 # touch modules/exampleauth/enable 

終わったらhttp://xxx.xxx.xxx/simplesaml/saml2/idp/metadata.phpにアクセスしてみましょう。

XMLが表示されたらその内容をメモっておきます。

必要となるのは「md:EntityDescriptorのentityId」「ds:X509Certificateの証明書文字列」

「md:SingleLogoutServiceのLocation」「md:SingleSignOnServiceのLocation」です。

 

では、SPに登録しましょう。

・・・・・とその前にSPの証明書を作成します;;;(またかよ・・・)

これも実働環境だと(ry

# cd /var/www/ssoapp/plugins
# mkdir cert
# cd cert
# openssl req -newkey rsa:2048 -new -x509 -days 3652 -nodes -out server.crt -keyout server.pem

 

作成した証明書をプラグインに設定します。

# cd ..
# cd config
# vi app.php
<?php
return [
'saml_config' => [
'baseurl' => 'http://xxx.xxx.xxx/ssoapp',
'sp' => [
'entityId' => 'http://xxx.xxx.xxx/ssoapp',
'assertionConsumerService' => [
'url' => 'http://xxx.xxx.xxx/ssoapp/saml-auth/login',
],
'singleLogoutService' => [
'url' => 'http://xxx.xxx.xxx/ssoapp/saml-auth/logout',
],
'NameIDFormat' => 'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress',
'x509cert' => '{server.crtの中身をコピペ}',
'privateKey' => '{server.pemの中身をコピペ}'
],
'idp' => [
'entityId' => 'md:EntityDescriptorのentityId',
'singleSignOnService' => [
'url' => '{md:SingleSignOnServiceのLocation}',
],
'singleLogoutService' => [
'url' => '{md:SingleLogoutServiceのLocation}',
],
'x509cert' => '{ds:X509Certificateの証明書文字列}'],
]
];

 

保存したらhttp://xxx.xxx.xxx/ssoapp/saml-auth/metadataを表示してみてください。

XMLが表示されたらOKです。例によってこのXMLの情報をIdp設定で使用します。

 

●SPの証明書情報をIdpに登録

# vi /var/www/simplasaml/metadata/saml20-sp-remote.php
// 以下を追記
$metadata['http://xxx.xxx.xxx/ssoapp/'] = array(
'AssertionConsumerService' => 'http://xxx.xxx.xxx/ssoapp/saml-auth/login',
'SingleLogoutService' => 'http://xxx.xxx.xxx/ssoapp/saml-auth/logout',
'NameIDFormat' => 'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress',
'simplesaml.nameidattribute' => 'uid',
'simplesaml.attributes' => FALSE,
);

 

認証用アカウント(ID=test, Pass=test)を作成

# vi /var/www/simplasaml/config/authsources.php
<?php
$config = array(
    'example-userpass' => array(
        'exampleauth:UserPass',
        'test:test' => array(
            'uid' => array('test'),
            'eduPersonAffiliation' => array('member', 'employee'),
        ),
    ),

これで完了です。

 

 

■動作確認

http://xxx.xxx.xxx/loginにアクセスするとIdp側のログイン画面にリダイレクトされます。

そこで認証が完了すればSP側に戻って認証情報が参照できるはずです。

 

・動作サンプル




 

 

 

参考)

 

2016年11月7日

Docker + LDAP+ MailServer(Postfix + dovecot) + Roundcubeを構築する

Filed under: Docker,Linux,OSS,postfix,Roundcube,オープンソース — ranpei @ 3:11 AM

ちょっと流れから脱線しますが、

Dockerを使ってのメールサーバー構築に成功したため

その内容をメモとして残します。

 

1.メールサーバーの要件

現在のメールサーバーの使い方なのですが、

以下の2つがあるためこれらを満たす必要があります。

・サービス毎のメールアカウント管理

・フリーメールの集約

サービス毎のメールアカウントを管理するのは前にも言ったようにLDAPL+バーチャルメールボックスで行けるのですが、

フリーメールの集約はFetchmailを使っているためこれが動作する環境である必要があります。

ではできるのか?というとRoundcubeにはFetchmailの設定をWeb上で行えるプラグインが存在します。

ですが、Fetchmailは取得したメールをローカルのMDAにフォーワードすることしかできないのできません。

つまりRoundcube自身にプラグインが入った状態でなおかつローカルにMDAが存在する必要があるのです。

 

2.考えられる構成は?

考えられる構成は2種類あります。

1つは以下のようにすべてを1つのContainerにまとめること。

%e3%83%a1%e3%83%bc%e3%83%ab%e3%82%b5%e3%83%bc%e3%83%90%e3%83%bc_%e5%8d%98%e4%b8%80%e3%82%b3%e3%83%b3%e3%83%86%e3%83%8a

もう1つは以下のように転送用のメールサーバーを構築してメインのメールサーバーにメールを転送すること。

%e3%83%a1%e3%83%bc%e3%83%ab%e3%82%b5%e3%83%bc%e3%83%90%e3%83%bc_%e5%88%86%e9%9b%a2%e5%9e%8b

 

今回はどうしてもメールサーバーとRoundcubeは別に構築したかったため後者で構築を行いました。

 

3.メールサーバーを構築する

これらのContanerについては要件を満たすものがなかったため

DockerHub上のものを改造する形で自分で作りました。

GitHubに挙げてますのでダウンロードしてください。

 

// メールサーバーのチェックアウト
$ git clone https://github.com/gittrname/mailserver-ldap.git
// Roundcube + Fetchmailサーバーのチェックアウト
$ git clone https://github.com/gittrname/roundcube-fetchmail.git

・docker-compose.yml

version: '2'
services:  
  mail:  
    build: mailserver-ldap  
    ports:  
      - "25:25"  
      - "465:465"  
      - "587:587"  
      - "110:110" 
      - "143:143"  
      - "995:995"  
      - "993:993"  
    links:  
      - ldap  
    extra_hosts:  
      - "mail.example.com:127.0.0.1"  
    environment:  
      - "LDAP_SERVER=ldap"  
      - "DOMAIN=example.com"  
      - "HOSTNAME=mail.example.com" 
      - "LDAP_BASE=ou=People,dc=example,dc=com"  
      - "LDAP_USER_FIELD=uid"  
  roundcube:
    build: roundcube-fetchmail
    ports:
      - "80:80"
    links:
      - ldap
      - mail
    extra_hosts:
      - "fetch.example.com:127.0.0.1"
    environment:
      - "ROUNDCUBE_DEFAULT_HOST=mail"
      - "ROUNDCUBE_SMTP_SERVER=mail"
      - "ROUNDCUBE_USERNAME_DOMAIN=example.com"
      - "HOSTNAME=fetchmail.example.com"
  ldap:  
    image: sharaku/ldap  
    ports:  
      - "8080:80"  
    environment:  
      - "LDAP_DOMAIN=example.com"  
      - "LDAP_ADMIN_PWD=password"  
      - "LDAP_ORGANISATION=LDAP for docker."

 

※ RoundcubeとLdapAdminのポートが被らないようにしてください。

後はLdapAdmin上でユーザーを作成すればメールアカウントの作成は完了します。

 

 

定期的なメールの取得はログインした後「設定」⇒「Fetchmail]で設定します。

取得先のドメイン、ユーザー、パスワードを設定すると15分間隔でメールを取得し、

ログインユーザー@ドメインにメールを転送します。

 

ちょっとデータの永続化に多少の不安がありますが

一応、やりたいことはできたので公開してます。

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

 

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

Older Posts »

Powered by WordPress