20210801のdockerに関する記事は10件です。

【Ethereum】DockerコンテナにGethの環境を構築してみる

はじめに Ethereumネットワーク上でアプリを動かしてみようと思い、なるべくローカル環境を汚したくないのでDockerコンテナ上で環境を作れないかとやってみたら出来たので、その方法を備忘録として残しておこうと思います。 前提 ・Dockerの使い方についての説明はしません。 ・Macでの操作になります。Windowsの方は適宜あてはめてやってみてください。 そもそもGethとは GethはGoで実装されたEthereumのCUIクライアントで、このGethをインストールし起動することでEthereumのP2Pネットワークにフル・ノードとして参加することが出来ます。 Gethを使うことで、 ・etherの採掘 ・etherの送金 ・スマート・コントラクトの生成 ・トランザクションの生成 ・ブロックチェーンの確認 といった動作が可能になります。 Dockerfileの作成 てきとうなディレクトリに作業用フォルダを作成しそのフォルダでDockerfileを作成します。 Dockerfile FROM ubuntu:latest RUN apt-get update && apt install -y software-properties-common RUN add-apt-repository -y ppa:ethereum/ethereum RUN apt-get update && apt-get install -y \ ethereum \ solc WORKDIR /work/ 簡単に内容を説明すると、 1行目でOSとしてubuntuのイメージを取得しています。 2行目、3行目では、ethereumのパッケージはapt-getのパッケージリストに無いので、ethereumのパッケージリストをapt-getにインストールしています。 4行目、5行目でethereumのライブラリをコンテナにインストールしています。 6行目のsolcはスマートコントラクトのコードをデプロイする際コンパイルするためのツールです。 コンテナ内では作業用ディレクトリとしてroot配下にworkフォルダを作成しています。 dockerコンテナの作成 Dockerfileをビルドしdockerイメージを作成します。 $ docker build . dockerイメージが作成されたらそのイメージからコンテナを起動します。 # xxxxxxxxxはdockerのimage $ docker run -it -v ~/hoge:/work xxxxxxxxx bash docker runでコンテナを起動する際、-vオプションでホストのフォルダとコンテナのフォルダをマウントするのを忘れないよう注意。 Gethの確認 コンテナが起動したらGethとsolcがインストールされているか確認します。 1.Gethの確認 コンテナのコンソールでgethコマンドとversionサブコマンドを入力します。 root@064d11dd2cec:/work# geth version Geth Version: 1.10.6-stable Git Commit: 576681f29b895dd39e559b7ba17fcd89b42e4833 Architecture: amd64 Go Version: go1.16.4 Operating System: linux GOPATH= GOROOT=go こんな感じで表示されたらOK. 2.solcの確認 今回の記事では使用しないけど、いずれ使うので今の内に確認しておきます。 solcコマンドに--versionオプションをつけて実行します。 root@064d11dd2cec:/work# solc --version solc, the solidity compiler commandline interface Version: 0.8.6+commit.11564f7e.Linux.g++ こんな感じで表示されたらOK. これでコンテナ環境でGethを使ってEthereumのプライベートネットワークでetherの送金やマイニング、スマートコントラクトの作成をすることが出来るようになりました。 次回はgenesisファイル(ブロックチェーンの一番初めのブロックの設定ファイル)でのgeth初期化とgethの起動、etherの送金等を書いていこうと思います。 おわりに ブロックチェーンアプリ開発を勉強中です。 学んだことをアウトプットするため、また自分自身の備忘録として書いています。 他にも優良なサイトや記事はたくさんあるので、なるべく自分がハマった箇所をメインに記事を作成していこうと思っています。 もし自分と同じ箇所でハマっている方の参考になれば幸いです。 また気付いた点や間違えている点があったらご指摘いただけると嬉しいです。 参考サイト Ethereum入門 このサイトにはホントお世話になっています。EthereumやGethのことが細かく紹介されています。 渋谷ほととぎす通信 Ethereumの仕様は結構変わったりするんですが、このサイトは新しい情報が載っているので参考にしています。 apt-getで見つからないパッケージを追加する方法(debian, ubuntu両方対応) ubuntuにethereumをインストールする時の参考にしました。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

CentOSでライブラリ(yumコマンド)をインストールしようとしたらTimeOutしてしまってできなかった

はじめに インフラ系って何度やっても難しく感じますよね 私は普段からDockerを利用していまして、kubernetesがどんなものなのかよくわからなかったのでDevOpsの勉強がてら「たった1日で基本が身に付く! Docker/Kubernetes超入門」というのを休日を使ってやることにしました。 内容はある程度Dockerを使っている人ならスムーズにできるのですが、途中から仮想マシンの上でDockerを使う必要があり、Docker for Desktopではなく、Hyper-Vに仮想環境を作成して書籍を進める必要があります。 この仮想環境作成がかなり苦戦したので、今回はつまずいた点をまとめたいと思います。 環境 Hyper-V CentOS7 Docker 問題 まずは書籍通りに、CentOS7の環境を作成しました。 そして、dockerをインストールするため以下のコマンドを入力します。 yum install -y yum-utils device-mapper-persistent-data lvm2 yum-config-manager --add-repo https://download docker.com/linux/centos/docker-ce.repo (以下省略) すると、2行目で以下のようなエラーが発生します。 Loaded plugins: fastestmirror adding repo from: https://download.docker.com/linux/centos/docker-ce.repo grabbing file https://download.docker.com/linux/centos/docker-ce.repo to /etc/yum.repos.d/docker-ce.repo Could not fetch/save url https://download.docker.com/linux/centos/docker-ce.repo to file /etc/yum.repos.d/docker-ce.repo: [Errno 12] Timeout on https://download.docker.com/linux/centos/docker-ce.repo: (28, 'Operation timed out after 30000 milliseconds with 0 out of 0 bytes received') タイムアウトしてダウンロードできていないようです。 ネットワークの関係か私の環境ではダウンロードができませんでした。(最近ネット環境がひどいのもあります) (メモ: CentOSでコマンドを打つときにUS配列になっていました。「:」はShift + ;で入力できました。「=」は「^」です) 解決方法 タイムアウトまでの時間を長くすることで解決しました。 sudo vi /etc/yum.conf と入力して、 # 好きなところに以下の行を追加。viはESCキー→「:q」で終了。ただしUS配列は「:」のキーが違う timeout=1000 と追加することでダウンロードができました。 私の環境がかなり遅かったので1000にしました。 メモ CentOSの環境作成の時に1つ間違えて、それが原因でダウンロードできなかったのも起きたのでメモしておきます。 CentOSのインストール時に、ネットワークの設定を「ON」にする必要があります。 引用: CentOS 7 をインストール Linuxを始めるにはインストールからがお勧め この「ON」と「OFF」のスイッチを勘違いして、うまく設定できていませんでした。 いま、「OFF」とみえるので、状態は「OFF」になります。「ON」にするにはスイッチをクリックする必要があります。 以前、このボダンをおすと「OFF」になるよみたいなのがあったせいで勘違いしました。 以下のような状態にしましょう。 (引用元から借りさせていただきました) おわりに 1日で身につくという趣旨の本でしたが、2章やるのに1日を使ってしまいました。(5時間くらい) なぜか私のネットワークではインストールがかなり遅く、それにも多くの時間がかかりました。 インフラ系はとにかく躓いて、あきらめずに頑張るという感じではあるので今後も頑張っていきたいです。 とりあえず読了まではなんとかしたいですが、次はどんなエラーが起きるのでしょうか、、、、 参考 CentOS 7 をインストール Linuxを始めるにはインストールからがお勧め
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Windows HomeへDockerをインストールする方法

はじめに WindowsにDockerをインストールするのが難しかったのは一昔のこと。 今ではWindows10 Homeであっても、ものの10分程度でインストールすることができます。 Dockerの進化はとても早く、WindowsへのDockerインストールはWSL2が出たことによってとても簡単になったので、普及も兼ねて記事にまとめたいと思います。 Windowsのバージョン確認、アップデート 以下の操作(Windows HomeへのDockerインストール)を行うためには、Windowsをバージョン2004、ビルド19041以上にアップデートする必要があります。 ※すでにバージョン2004以降であれば、この操作は不要です WSL2のインストール WSL2とはWindows Subsystem for Linux 2の略で、Windows10上でLinuxを動作させるための仕組みです。 WSL2を使うと簡単にWindows上でLinuxを扱うことができるようになります。 1.PowerShellを管理者権限を起動します。 Windowsキーを押し、PowerShellと入力し、「管理者として実行する」を選択します。 2.管理者として実行しているPowerShellで下記を実行し、Linux 用 Windows サブシステムを有効します。 「操作は正常に完了しました。」と表示されれば成功です。 dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart 3.管理者として実行しているPowerShellで下記を実行し、仮想マシンの機能を有効にします。 「操作は正常に完了しました。」と表示されれば成功です。 その後、パソコンを再起動します。 dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart 4.Linuxカーネル更新プログラムパッケージをダウンロードします。 5.WSL2を既定のバージョンとして設定します。 PowerShellを開いて次のコマンドを実行し、新しいLinuxディストリビューションをインストールする際の既定のバージョンとしてWSL2を設定します。 「WSL2との主な違いについては、https://aka.ms/wsl2 を参照してください」と表示されれば成功です。 wsl --set-default-version 2 6.Windowsキーを押し、MicrosoftStoreから「Ubuntu 20.04 LTS」をインストールします。 インストールが終わったら起動し、ユーザーネームとパスワードを入力します。 パスワードは必ず忘れないようにしましょう。入力が終わったら一旦Ubuntuは閉じます。 ※マイクロソフトアカウントの登録がなくてもインストールは可能です 7.PowerShellを開いて次のコマンドを実行し、Ubuntuがデフォルトになっているか確認します。 wsl -l -v 叩いた結果が以下のように、Ubuntuに*印が付いていれば成功です。 *印が付いているものがデフォルトです。 NAME STATE VERSION * Ubuntu-20.04 Running 2 もしUbuntuに付いていなければ、デフォルトを切り替えます。 wsl --set-default Ubuntu-20.04 以上でWSL2関連の対応はすべて完了です。 Docker Desktop for Windowsのダウンロード こちらからDocker Desktopをダウンロードし、パソコンにインストールします。 途中、チェックボックスの選択する場面がありますが、基本的にはデフォルトのままで問題ありません。 Windowsターミナルのインストール Dockerへのアクセスやコマンドの実行のためのターミナルをインストールします。 タブの分割などができたり、外観を変更したり等、自分好みにカスタマイズすることができます。 Windowsキーを押し、MicrosoftStoreから「Windows Terminal」をインストールします。 ※マイクロソフトアカウントの登録がなくてもインストールは可能です Docker導入時に一緒に追加されるディストリビューションについて docker導入後にPowerShellで「wsl -l -v」を実行すると、「docker-desktop-data」と「docker-desktop」というのが表示されます。 これはWSL2のディストリビューションとして作られたものがマウントされているようです。 こちらを使わずにubuntu-20.04側を使うようにしましょう。 PS C:\hogehoge> wsl -l -v NAME STATE VERSION * Ubuntu-20.04 Running 2 docker-desktop Running 2 docker-desktop-data Running 2 補足 WSL2を導入した場合、ターミナルで次のコマンドを実行すると、該当箇所をエクスプローラーで開くことができます。 explorer.exe . また逆に、エクスプローラーで「\wsl$」と入力するとWSLへアクセスできます。 関連サイト
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Dockerとラズパイで迫撃砲(簡単開発支援サーバ)

迫撃砲(簡単開発支援サーバ)って何? ※wikipediaからの引用 迫撃砲(簡単開発支援サーバ)は以下のような機能を持つサーバです. Gitレポジトリ管理 自動テスト ただのCIサーバです.しかし、最大の特徴はラズパイ上で動作する点です.小型で低価格なので以下のような場面で活躍します. CIサーバを購入できない貧乏チーム CIサーバを試してみたいチーム 出先で行った変更に対して自動テストを実行したい 所詮はラズパイなのでストレージ容量やCPU性能に物足りないところもあります.されど、小型なので迫撃砲(簡単開発支援サーバ)は鞄に忍びこませることができます.家でセットアップして職場に持っていくだけで速攻でCIサーバを展開できます.また、出先にも持っていけるので出張先から自社のサーバにアクセスするのに必要となる面倒なVPNの設定も必要ありません.稼働状況の表示やテストなどサーバの保守を支援する機能が搭載されているので少人数(というか一人?)での運用もできます.迫撃砲のように現場で迅速展開、仲間のために支援砲火をバカスカ打てます. この記事では20人ほどの開発チームに低予算でラズパイを用いた迫撃砲(簡単開発支援サーバ)を導入することを目的に書きます. ハードウェア サーバのハードウェアにはラズパイを使用します. ラズパイはamazonで購入できます. 基盤むき出しだと不慮の事故で壊れる可能性があるのでケースも買っておきましょう. 筆者はラズパイ4で構築しています. ケースをつけた状態でタバコサイズです.胸ポケットに入るCIサーバです. ラズパイにはラズパイ3とラズパイ4があります.検証はしていませんが、ラズパイ3でもこの記事に書かれた方法で構築できると思います. ラズパイの基本設定 ラズパイをサーバとして動作させるには以下の設定をします. IPアドレスの固定 ファイヤーウォールの設定 パスワード変更 ssh認証鍵の設定 IPアドレスの固定 IPアドレスの割当を行うdhcpcdデーモンの設定を変更して静的なIPをラズパイに割当てます. /etc/dhcpcd.confの以下の行を変更してください. /etc/dhcpcd.conf interface eth0 static ip_address=<割り当てるIPアドレス/ネットマスク> static routers=<ルータのアドレス> static domain_name_servers=<ルータのアドレス(DNSサーバのアドレス)> 変更後、ラズパイを再起動します. sudo reboot ファイヤーウォールの設定 以下のコマンドでufwをインストールします. sudo apt install ufw ufwの設定、すなわち許可するポートの設定を行います. 許可すべきポートは以下のとおりです. サービス ポート ssh 22 ssh(For Gitea) 222 http 80 glance 20000 testinfra 30000 以下のコマンドで上記のポートを有効化できます. sudo ufw allow ssh sudo ufw allow http sudo ufw allow 20000/tcp sudo ufw allow 30000/tcp sudo ufw allow 222/tcp 設定が終わったら以下のコマンドでufwを起動します. sudo ufw enable 確認のため最後にsudo ufw statusで状態を表示しましょう. Status: active To Action From -- ------ ---- 22/tcp ALLOW Anywhere 80/tcp ALLOW Anywhere 20000/tcp ALLOW Anywhere 30000/tcp ALLOW Anywhere 222/tcp ALLOW Anywhere 22/tcp (v6) ALLOW Anywhere (v6) 80/tcp (v6) ALLOW Anywhere (v6) 20000/tcp (v6) ALLOW Anywhere (v6) 30000/tcp (v6) ALLOW Anywhere (v6) 222/tcp (v6) ALLOW Anywhere (v6) 22 (v6) DENY Anywhere (v6) 意図した通りにファイヤーウォールが設定されているでしょうか?上記のように表示されたら完了です. パスワードの変更 デフォルトのパスワードはraspberryです.これをそのまま使って置くことはセキュリティリスクとなります.忘れずに変更しましょう. 以下のコマンドで変更できます. passwd 変更後のパスワードは忘れないように書き留めておきましょう. ssh認証鍵の設定 パスワードを使ったログインは手軽ですが総当り攻撃や辞書攻撃によって簡単に破られる可能性があります. そこで、認証鍵を用いたログインを行うようにします. クライアント側で認証鍵を生成します. ssh-keygen -t rsa 生成された~/.ssh/id_rsa.pubをラズパイにインストールします. ssh-copy-id -i ~/.ssh/id_rsa.pub pi@<ラズパイのIP> sshでラズパイにログインしましょう. ssh pi@<ラズパイのIP> ログイン後、不要となったパスワードによるログインを禁止します. ラズパイの/etc/ssh/sshd_configの以下の行を変更します. /etc/ssh/sshd_config ChallengeResponseAuthentication no # ここをyes -> noにする ... PasswordAuthentication no # ここをyes -> noにする ... UsePAM no # ここをyes -> noにする ついでにROOTでのログインも禁止しておきましょう. /etc/ssh/sshd_config PermitRootLogin no # ここをyes -> noにする 変更を反映するためにsshdデーモンを再起動します. sudo service sshd restart システムの立ち上げ これまででサーバとしての基本部分の設定が完了しました. もちろんこのままでは迫撃砲(簡単開発支援サーバ)としては不十分です. これからサーバとしての機能を構築していきます. 以下が迫撃砲(簡単支援サーバ)の全体像です. 迫撃砲のシステムは大きく2つの部分に大別されます. サーバ管理システム サーバの稼働状況の監視、テスト、サーバの起動を行うシステムです.以下のソフトから構成されます. glances(サーバ稼働状況の表示) testinfra(単体テストの実行+ウェブページによる結果の表示) Webアプリケーションシステム レポジトリ管理ソフトとしてGitTea、自動テストソフトとしてJenkinsを稼働させます. これらのソフトはDocker Engine上で動作します. サーバの構築に使用したコードは以下のGithubレポジトリにアップロードしています.以降はこのレポジトリを参照しながら読み進めてください. サーバ管理システムのセットアップ glancesのセットアップ glancesはサーバの稼働状況を表示するPythonアプリです.サーバの稼働状況を調べるのにいちいちsshでログインするのは面倒です.そこで、ウェブブラウザで使ってサーバにアクセスするだけでサーバの稼働状況を調べられるようにします. まず、ラズパイにPython3とpipをインストールします.以下のコマンドでインストールできます. sudo apt-get install -y python3 python3-pip 次にインストールしたpipを使ってglancesをインストールします. sudo pip3 install glances インストールが終わったらの以下のコマンドを起動してglancesウェブサーバを起動します. glances -w --username --password --port 20000 デフォルトのパスワードの入力が求められるので入力して、その後の指示に従い保存してください. ウェブブラウザでhttp://<ラズパイのIP>:20000 を開くとサーバ稼働状況が表示されます. testinfra+Flaskのセットアップ testinfraはPythonで実装されたサーババリデーションモジュールです.testinfraを使えばPythonスクリプトから ストレージ容量 実行しているDockerコンテナ コマンドの実行結果 取得することができます.この機能を使ってサーバが望ましい状態で稼働しているかをテストすることができます. ただし、testinfraにはglancesのようにウェブページを介して表示する機能はありません. そこで、Flaskと組み合わせることでウェブページからサーバのテスト結果を表示できるようにします. まず以下のコマンドでtestinfraとFlaskをインストールします. sudo pip3 install testinfra Flask 以下のようなPythonスクリプトを用意します. server.py from flask import Flask, render_template import testinfra from datetime import datetime import humanfriendly import io app = Flask(__name__) @app.route('/') def index(): print("Test Executed!!") contents = "Test Result:</br>" return render_template('layout.html', title = 'Test', datetime =datetime.now() ,test_all = test_all) def test_all(): result = {} try: host = testinfra.host.get_host("local://", sudo=True) # test password file for root access rights passwd = host.file("/etc/passwd") result["Password Root"] = "OK" if passwd.contains("root") else "NG" result["Password User"] = "OK" if passwd.user == "root" else "NG" result["Password Group"] = "OK" if passwd.group == "root" else "NG" result["Password Mode"] = "OK" if passwd.mode == 0o644 else "NG" # test local host resolvable localhost = host.addr("localhost") result["localhost Resovable"] = "OK" if localhost.is_resolvable else "NG" # test wan dns wan_dns = host.addr("8.8.8.8") result["WAN DNS Reachable"] = "OK" if wan_dns.is_reachable else "NG" # test sshd sshd = host.service("sshd") result["sshd running"] = "OK" if sshd.is_running else "NG" ssh_port = host.socket("tcp://0.0.0.0:22") result["ssh port"] = "OK" if ssh_port.is_listening else "NG" # test ufw ufw = host.service("ufw") result["ufw running"] = "OK" if ufw.is_running else "NG" # test glances glances_http = host.run("sudo curl -Is http://192.168.11.20:20000 | head -1") result["glances working"] = "OK" if 'HTTP/1.0 401 Unauthorized' in glances_http.stdout else "NG" # test docker docker = host.service("docker") result["docker running"] = "OK" if docker.is_running else "NG" nginx = host.docker("nginx") result["docker nginx"] = "OK" if nginx.is_running else "NG" gitea = host.docker("gitea") result["docker gitea"] = "OK" if gitea.is_running else "NG" giteadb = host.docker("giteadb") result["docker giteadb"] = "OK" if giteadb.is_running else "NG" jenkins = host.docker("jenkins") result["docker jenkins"] = "OK" if jenkins.is_running else "NG" docker_df = host.run("sudo docker system df --format='{{.Size}}'").stdout size = 0 for line in io.StringIO(docker_df): size += humanfriendly.parse_size(line) print(size) result["docker size"] = "OK" if size < 8000000000 else "NG" # test gitea gitea_http = host.run("sudo curl -Is http://192.168.11.20/gitea/ | head -1") result["gitea working"] = "OK" if 'HTTP/1.1 200 OK' in gitea_http.stdout else "NG" # test jenkins jenkins_http = host.run("sudo curl -Is http://192.168.11.20/jenkins/login | head -1") result["jenkins working"] = "OK" if 'HTTP/1.1 200 OK' in jenkins_http.stdout else "NG" # test directory size gitea_file = host.file("/root/Server/Docker/Gitea/gitea-data/") result["gitea file size"] = "OK" if gitea_file.size < 4000000000 else "NG" giteadb_file = host.file("/root/Server/Docker/GiteaDB/giteadb-data/") result["giteadb file size"] = "OK" if giteadb_file.size < 2000000000 else "NG" jenkins_file = host.file("/root/Server/Docker/Jenkins/jenkins_home/") result["jenkins file size"] = "OK" if jenkins_file.size < 4000000000 else "NG" except: err = sys.exc_info()[0] result["Unit test bail out!!"] = err return result if __name__ == '__main__': app.config['TESTING'] = False app.config['DEBUG'] = False app.run(host='0.0.0.0', port=30000) server.pyはウェブページの描画にlayout.htmlを参照します.layout.htmlはテスト結果をhtmlの表として出力します. layout.htmlの内容は割愛します. server.pyは以下のコマンドで起動ます. sudo python3 server.py 起動したらウェブブラウザで<ラズパイのIP>:30000にアクセスしましょう. テスト結果が表示されます. テストはserver.pyのtest_allに実装されています.test_allは以下のテストを実行しています. WANへのアクセスのチェック sshサービスの稼働チェック ufwサービスの稼働チェック Giteaコンテナの稼働状態のチェック Jenkinsコンテナの稼働状態のチェック curlコマンドを用いたGiteaページへのアクセス curlコマンドを用いたJenkinsページへのアクセス Giteaのストレージの容量チェック Jenkinsのストレージの容量チェック 忘れていましたがserver.pyの実行にはcurlが必要です.以下のコマンドでcurlをインストールしましょう. sudo apt-get install -y curl 起動・停止スクリプトの作成 以上でサーバ管理システムのセットアップが完了しました. 簡単にglancesとtestinfra+Flaskを起動・停止できるようにスクリプトを用意しましょう. githubのレポジトリのstart_server.shは起動スクリプト、stop_server.shは停止スクリプトです. 起動スクリプトの内容は以下のとおりです. start_server.sh #! /bin/bash pushd $(dirname ${BASH_SOURCE}) 1> /dev/null # launch glances printf "<設定したglancesのパスワード>" | glances -w --username --password --port 20000 1> /dev/null 2> /dev/null & disown # launch testinfra pushd ./testinfra 1> /dev/null python3 server.py 1> /dev/null 2> /dev/null & disown popd 1> /dev/null popd 1> /dev/null 停止スクリプトは以下のとおりです. stop_server.sh #! /bin/bash pushd $(dirname ${BASH_SOURCE}) 1> /dev/null # stop glances pkill glances # stop testinfra pkill -f server.py popd 1> /dev/null 以下のコマンドでスクリプトを実行すればサーバの起動と停止ができます. # 実行権限の付与 chmod +x start_server.sh chmod +x stop_server.sh # 起動 ./start_server.sh #停止 ./stop_server.sh 自動起動の設定 ラズパイの電源をオフすると迫撃砲(簡単開発支援サーバ)は停止してしまいます. 電源オンオフの度にstart_server.shを実行するのは非常にたるいです. そこで起動時にstart_server.shが自動的に実行されるようにします. 起動にはsystemdを使います. systemdはLinuxのシステム管理デーモンです.systemdを使えば起動時や定期的にプログラムを実行できます. 設定のために新たなサービスを作成します. 以下の内容のsds.serviceファイルを/etc/systemd/system/に配置します. /etc/systemd/system/sds.service # place this files in /etc/systemd/system/ [Unit] Description = Software Development Server Requires=docker.service [Service] Type=oneshot ExecStart=<start_server.shへのパス> ExecStop=<stop_server.shへのパス> RemainAfterExit=true [Install] WantedBy=multi-user.target 以下のコマンドで追加されたsds.serviceファイルをsystemdに反映します. sudo systemctl daemon-reload 以下のコマンドで起動時にsds.serviceが起動時に実行されるようにします. sudo systemctl enable sds これにより、ラズパイの起動時に自動的にソフトウェア開発支援サーバが起動されます. Webアプリケーションシステムの立ち上げ Webアプリケーションシステムを立ち上げます. 立ち上げにはDockerを使います.Dockerはコンテナと呼ばれる仮想環境上でOSとアプリをまるごと動作させることができます. これにより、一台のラズベリーパイの中であたかも複数のサーバが動いているかのように動作させることができます. docker-composeの設定 サーバを起動するときはdocker-composeを介してDockerを呼び出します. docker-coposeはDockerの補助スクリプトです.docker-compose.ymlに記述された設定の通りに複数のサーバを起動・停止します. なくても良いのですがDockerの複雑な引数を簡単に呼び出せるようにしてくれるので、docker-composeを使ったほうがコマンドの実行が非常に楽になります. Docker/docker-compose.ymlの内容は以下のとおりです. Docker/docker-compose.yml version: "3" networks: giteanet: external: false jenkinsnet: external: false services: nginx: image: nginx:alpine depends_on: - gitea - jenkins container_name: nginx volumes: - ./Nginx/nginx.conf:/etc/nginx/nginx.conf:ro - /etc/timezone:/etc/timezone:ro - /etc/localtime:/etc/localtime:ro networks: - giteanet - jenkinsnet ports: - 80:80 - 222:222 giteadb: image: arm32v7/postgres container_name: giteadb environment: POSTGRES_DB: giteadb POSTGRES_USER: gitea POSTGRES_PASSWORD: gitea logging: driver: "json-file" options: max-file: "2" max-size: "3m" restart: unless-stopped networks: - giteanet volumes: - ./GiteaDB/giteadb-data:/var/lib/postgresql/data - /etc/timezone:/etc/timezone:ro - /etc/localtime:/etc/localtime:ro gitea: image: kunde21/gitea-arm container_name: gitea environment: - GITEA__database__DB_TYPE=postgres - GITEA__database__HOST=giteadb:5432 - GITEA__database__NAME=giteadb - GITEA__database__USER=gitea - GITEA__database__PASSWD=gitea logging: driver: "json-file" options: max-file: "2" max-size: "3m" restart: unless-stopped depends_on: - giteadb networks: - giteanet links: - "giteadb" volumes: - ./Gitea/gitea-data:/data/ - ./Gitea/app.ini:/data/gitea/conf/app.ini - /etc/timezone:/etc/timezone:ro - /etc/localtime:/etc/localtime:ro jenkins: build: context: ./Jenkins container_name: jenkins environment: - JENKINS_OPTS="--prefix=/jenkins" logging: driver: "json-file" options: max-file: "2" max-size: "3m" restart: unless-stopped networks: - jenkinsnet volumes: - ./Jenkins/jenkins_home:/var/jenkins_home - /etc/timezone:/etc/timezone:ro - /etc/localtime:/etc/localtime:ro volumes: giteadb-data: driver: local driver_opts: type: 'none' o: 'bind' device: './giteadb-data/' gitea-data: driver: local driver_opts: type: 'none' o: 'bind' device: './gitea-data/' jenkins_home: driver: local driver_opts: type: 'none' o: 'bind' device: './jenkins_home/' ラズパイのポート80とポート222をNginxコンテナのポート80と222にバインドします. JenkinsとGiteaとGiteaDBサーバはNginxを介して外部と通信行います. さらにJenkinsとGiteaは個別のDockerネットワークに配置されます. これにより、 GiteaとJenkinsで同じポートが使える セキュリティの向上 ができます. Nginxの設定 ラズパイ内で複数のサーバを動かしたい場合、ポートやURLでサーバへのアクセスを切り替える必要があります. そこで、Nginxを使います.Nginxはnginx.confに記述されたルールに基づいてサーバへのアクセスを適切なサーバに転送します. 以下がnginx.confの内容です. nginx.conf user nginx; worker_processes auto; error_log /var/log/nginx/error.log notice; pid /var/run/nginx.pid; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; #tcp_nopush on; keepalive_timeout 65; gzip on; upstream jenkins { keepalive 32; # keepalive connections server jenkins:8080; # jenkins ip and port } # Required for Jenkins websocket agents map $http_upgrade $connection_upgrade { default upgrade; '' close; } server { listen 80; # Listen on port 80 for IPv4 requests server_name 127.168.11.20; # replace 'jenkins.example.com' with your server domain name client_max_body_size 100M; # pass through headers from Jenkins that Nginx considers invalid ignore_invalid_headers off; location /gitea/ { proxy_pass http://gitea:3000/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location ~ "^/static/[0-9a-fA-F]{8}\/(.*)$" { # rewrite all static files into requests to the root # E.g /static/12345678/css/something.css will become /css/something.css rewrite "^/static/[0-9a-fA-F]{8}\/(.*)" /$1 last; } location /userContent { # have nginx handle all the static requests to userContent folder # note : This is the $JENKINS_HOME dir root /var/lib/jenkins/; if (!-f $request_filename){ # this file does not exist, might be a directory or a /**view** url rewrite (.*) /$1 last; break; } sendfile on; } location / { sendfile off; proxy_pass http://jenkins; proxy_redirect default; proxy_http_version 1.1; # Required for Jenkins websocket agents proxy_set_header Connection $connection_upgrade; proxy_set_header Upgrade $http_upgrade; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_max_temp_file_size 0; #this is the maximum upload size client_max_body_size 10m; client_body_buffer_size 128k; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffering off; proxy_request_buffering off; # Required for HTTP CLI commands proxy_set_header Connection ""; # Clear for keepalive } } } stream { upstream ssh { server gitea:222; } server { listen 222; listen [::]:222; proxy_pass ssh; } } nginx.confで行っている設定は以下のとおりです. ポート222のアクセスをGiteaコンテナに転送 /gitea/パスへのアクセスをGiteaコンテナに転送 それ以外はJenkinsコンテナに転送 Giteaの設定 Docker内で複数のサーバを起動します.先述した通りDocker内のサーバへのアクセスをパスで振り分けます. GiteaはNginxから転送されたURLに対応するためにサーバ設定を変更する必要があります. 以下が変更内容です. app.ini ; 省略 [server] DOMAIN = <ラズパイのIP> SSH_DOMAIN = <ラズパイのIP> ; 省略 ROOT_URL = http://<ラズパイのIP>/gitea/ ; 省略 Jenkinsの設定 セキュリティのためJenkinsでビルドをしたい場合はビルド環境をJenkinsノードという別のサーバにセットアップします. しかし、これ以上ラズパイで起動するサーバを増やすと設定が複雑になるだけでなくCPUが限界を迎えそうです. そこで、JenkinsコンテナにC/C++のビルド環境をセットアップして、Jenkinsだけでビルドを実行できるようにします. ビルド環境のセットアップにはDocker/Jenkins/Dockerfileに記述します. Dockerfile FROM jenkins4eval/jenkins USER root RUN apt-get update && apt-get upgrade -y RUN apt-get install -y build-essential cmake astyle RUN apt-get install -y python3 python3-pip RUN pip3 install virtualenv USER jenkins EXPOSE 8080 EXPOSE 50000 ENTRYPOINT ["/sbin/tini", "--", "/usr/local/bin/jenkins.sh"] jenkins4evalイメージに python3 pip build-essential(gccやmakeなど) cmake astyle(コード整形ツール) を追加して実行できるようにしています. Dockerの起動 設定したDockerの起動にはdocker-compose.ymlがあるディレクトリで以下のコマンドを実行します. sudo docker-compose up 自動起動・停止できるようにこの処理をstart_server.shとstop_server.shに追記します. 追記したあとのstart_server.shとstop_server.shは以下のとおりです. start_server.sh #! /bin/bash pushd $(dirname ${BASH_SOURCE}) 1> /dev/null # launch glances printf "youkan" | glances -w --username --password --port 20000 1> /dev/null 2> /dev/null & disown # launch testinfra pushd ./testinfra 1> /dev/null python3 server.py 1> /dev/null 2> /dev/null & disown popd 1> /dev/null # ↓ added for Docker↓ # launch docker servers pushd ./Docker 1> /dev/null # set up data directories if not exist mkdir -p "./Gitea/gitea-data/" mkdir -p "./GiteaDB/giteadb-data/" mkdir -p "./Docker/Jenkins/jenkins_home/" docker-compose up -d & disown popd 1> /dev/null # ↑ added for Docker↑ popd 1> /dev/null stop_server.sh #! /bin/bash pushd $(dirname ${BASH_SOURCE}) 1> /dev/null # stop glances pkill glances # stop testinfra pkill -f server.py # ↓ added for Docker↓ # stop docker server pushd ./Docker 1> /dev/null docker-compose down popd 1> /dev/null # ↑ added for Docker↑ popd 1> /dev/null サーバの使い方 初回起動時はJenkinsのパスワードを入力する必要があります. パスワードファイルはjenkinsコンテナの/var/jenkins_home/secrets/initialAdminPasswordファイルに記述されています. 以下のコマンドでファイルの中身を読み出しましょう sudo docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword Giteaにアクセスしたい場合はウェブブラウザを使って以下のURLにアクセスします. http://<ラズパイのIP>/gitea/ Jenkinsにアクセスしたいときはウェブブラウザを使って以下のアドレスにアクセスします. http://<ラズパイのIP>/jenkins/ あとは通常のGiteaとJenkinsです. サーバの保守 できればサーバの稼働状況をメールで通達するような仕組みが望ましいのです.しかし、そうなるとラズパイにメールサーバの設定をしなければなりません.メールサーバの設定を行うと迫撃砲(簡単開発支援サーバ)の魅力である「持っていって設置するだけで支援砲火を打てる」ができなくなります.そこで、稼働状況の通知は諦めてかわりに簡単に確認できるようにしました. ウェブブラウザで指定されたポートにアクセスするだけでサーバの状況を把握できるようになっています. サーバの稼働状況の表示 <サーバのIP>:20000にアクセスするとglancesのページが表示されます. このページから 実行中のプロセスの状態 CPUとメモリの消費量 ストレージの消費量 が表示されます. 単体テストの実行 <サーバのIP>:30000にアクセスるとtestinfraを使った単体テストが実行されます. テスト結果はウェブブラウザに表示されます. 問題があった場合、表にNGが表示されます.NGとなったテストが現れたときはserver.pyの内容と照らし合わせながら原因を追求します. サーバの移行 今回構築した迫撃砲(簡単開発支援サーバ)は少人数のチームのためのものです. チームの人数が増えてストレージ容量が足りなくなって来たらサーバの移行を検討しましょう.幸い単体テストにサーバのストレージ容量をチェックする項目があります.定期的に単体テストの結果をチェックすればストレージ容量不足の前兆を見逃しません.単体テストのストレージ消費量の項目はストレージの消費量が70%を超えたらNGになります.NGが出たら移行を検討すべきです. glancesとtestinfraはPythonで実装されているので普通の(x86アーキテクチャのCPUを搭載する)サーバで普通に動きます. 問題はDockerで動作するJenkinsとGiteaです.これらはarmアーキテクチャのためのイメージを使っています. 無理矢理x86アーキテクチャのサーバを動かそうとするとCPUアーキテクチャが違うので動作しません. JenkinsとGiteaのイメージを移行先のサーバのCPUアーキテクチャに合わせたイメージに差し替えましょう. サーバのデータは以下のディレクトリに格納されています. Docker/Gitea/gitea-data/ Docker/GiteaDB/giteadb-data/ Docker/Jenkins/gitea-data/ 移行先にそのままこれらのディレクトリの中身をコピーすれば移行完了です. データのバックアップもこれらのディレクトリの中身をバックアップするだけで良いです. 注意点 「隊長!!敵(ネットワーク管理者)にわれわれの位置がバレたようです!!」 「よし.潮時だな.位置を変えるぞ!!」 (使用に際してはちゃんと許可をとってください.) 参考文献 How to set a Raspberry Pi with a static ip address? SSH公開鍵認証で接続するまで How to disable ssh password login on Linux to increase security Github:nicolargo/glances Testinfra test your infrastructure freedesktop.org:systemd Gitea Nginx Jenkins Docker Draw.io Wikipedia:迫撃砲 補足 この記事は Qiitaエンジニアフェスタ_Dockerシステム構成 Qiitaエンジニアフェスタ_開発環境 の応募のために作成されました. Qiitanぬいぐるみがほしい!!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【簡単】nodejsがインストール済のlinuxのコンテナを作成する【備忘録】

Dockerfile作成 Dockerfile FROM node:12 ENTRYPOINT /bin/bash あとはDockerfileのあるディレクトリで docker build -t image_name . でイメージをビルドし、 docker run -it image_name でnodejsがインストール済みのlinuxのシェルにアクセスできます。 ちなみにlinuxのディストリビューションはdebainです。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

DockerとVisual Studio Codeで開発環境を作る

はじめに 表題の通りです。 今までDockerもVSCodeも別々に使っていました。 今更ですがDockerでVSCodeを使えるようにしていきます。 Remote Development with VS Code この機能を使うと、以下の3つの環境にVSCodeからリモート接続して開発できるようになります。 その前に まず、使わないやり方 ・ローカルで開発したソースをDockerにコピーする ・ローカルの特定ディレクトリをDockerにマウントする ローカルで開発したソースをDockerにコピーする 以前、使わないやり方でRust公式ドキュメントを試したことがあるので内容はこちらを参考にしてください。 Rust公式ドキュメントをDockerコンテナ上で進めてみる(1. 事始め, 2.数当てゲーム) こちらでは、以下の役割分担となっていました。 作業 ローカル環境(PC) 開発環境(Docker) Rustのインストール ー ○ Rustのコーディング ○ ー Rustのビルド ー ○ Rustの実行 ー ○ 使っていたDockerfile FROM rust:latest WORKDIR /usr/src/projects COPY . . # 2.数当てゲームをプログラミングする RUN cargo init guessing_game --bin && \ cd /usr/src/projects/guessing_game && \ cargo build WORKDIR /usr/src/projects/guessing_game CMD ["cargo", "run"] ローカルでuessing_game/main.rcを作成しディレクトリごとCOPY . .でDocker側にコピーしています。 ローカルを汚さないコンセプトでやっていたのでVSCodeにRust拡張を入れることもしませんでした。 公式ドキュメントをなぞるだけであれば問題ないですが、通常は動作確認が不可になるのでローカルにもRustを入れてビルド実行できるようにするかと思います。 以下はWeb上でRustの動作確認ができますので、ビルドが通ることの確認だけでしたらばローカルにIDEを入れる必要もないですがきちんとサービスを開発するのには向かないです。 https://play.rust-lang.org/ ローカルの特定ディレクトリをDockerにマウントする 開発とDocker内での動作確認(ビルド)を並行できる点が利点。 コピーとの違いは、DockerfileからCOPYとCMDを削除し、run時に以下を実行 # フルパスにしないとマウントされないので注意(空のフォルダがコンテナに作成されるだけ) $ docker run -it -v /Users/yukokanai/work/docker/bootstrap/mounted_folder/{開発ごとに作成}:/new_dir {image名} -- どちらの方法もターミナルウィンドウをいくつか準備したりとちょっと手間でした。 インストール こちらの手順からインストールを進めます。 Developing inside a Container - Installation VSCodeとDockerはローカル端末に入っているので以下の手順はスキップします。 1.Install and configure Docker for your operating system. 2.Install Visual Studio Code or Visual Studio Code Insiders. 3.Install the Remote Development extension pack. VSCodeにて、「Remote Development」を選択し、インストールします。 設定 まずは、適用するプロジェクトを新規に用意します。 ※すでにDockerfileを使っているものへの適用も可能です。 予めGitHubから適用するプロジェクト作成しクローンします。 $ git clone git@github.com:c3drive/smart_dog.git お試しでクイックスタートに従って進める インストール同様こちらの手順から進めます。 Developing inside a Container - Quick start VSCodeを開き、「Remote-Containers: Open Folder in Container...」を選択します。 先ほどクローンしたプロジェクトを選択します。 コンテナのOSイメージはrustを使いたかったので、「Show All Definions...」を選択します。 rustを選択すると設定が開始します。 完了後の画面は以下。VSCodeのTERMINALにてcargoが入っていることを確認します。 ちなみに私のローカル環境にrustやcargoはインストールしていません。以下はローカルのターミナル画面。 コンテナが起動していることもついでに確認してみます。 問題なく、動いていそうです。 ファイルを作成・変更してみる まずは、VSCodeのTERMINAL(コンテナ)からcargo new EXPLORERにhello_cargoフォルダが作成されました。 ローカル環境でも作成されています。 次にVSCodeエディタからファイル変更してみます。 src/main.rcに赤線部分を追記しました。 まずはローカル環境で確認 VSCodeではビルド実行までしてみます。 問題なさそうです。 実践 動作がわかったところで、自身が使うDockerfileを使った環境にしていきます。 プロジェクトは先ほどのものを使いますが、Remote周りで作成されたものはすべて削除し、Dockerfileを作成します。 (CMDがあると何か起きるかと思いましたが特に何も起きませんでした) 先ほどと同様に左下のマークから「Remote-Containers: Open Folder in Container...」を選択します。 OSイメージの選択画面が、先ほどとは違う表示となり、Dockerfileの選択肢に表示されているので選択します。 無事起動しました。 先ほどとはEXPLORERの構成と.devcontainer/devcontainer.jsonが異なります。 .devcontainer/devcontainer.jsonは、今後変更する必要が出てきそうでしたのでコードでも残しておきます。 用意されたrustを選択した場合 // For format details, see https://aka.ms/devcontainer.json. For config options, see the README at: // https://github.com/microsoft/vscode-dev-containers/tree/v0.187.0/containers/rust { "name": "Rust", "build": { "dockerfile": "Dockerfile" }, "runArgs": [ "--cap-add=SYS_PTRACE", "--security-opt", "seccomp=unconfined" ], // Set *default* container specific settings.json values on container create. "settings": { "lldb.executable": "/usr/bin/lldb", // VS Code don't watch files under ./target "files.watcherExclude": { "**/target/**": true } }, // Add the IDs of extensions you want installed when the container is created. "extensions": [ "rust-lang.rust", "bungcip.better-toml", "vadimcn.vscode-lldb", "mutantdino.resourcemonitor" ], // Use 'forwardPorts' to make a list of ports inside the container available locally. // "forwardPorts": [], // Use 'postCreateCommand' to run commands after the container is created. // "postCreateCommand": "rustc --version", // Comment out connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root. "remoteUser": "vscode" } 既存のDockerfileを選択した場合 // For format details, see https://aka.ms/devcontainer.json. For config options, see the README at: // https://github.com/microsoft/vscode-dev-containers/tree/v0.187.0/containers/docker-existing-dockerfile { "name": "Existing Dockerfile", // Sets the run context to one level up instead of the .devcontainer folder. "context": "..", // Update the 'dockerFile' property if you aren't using the standard 'Dockerfile' filename. "dockerFile": "../Dockerfile", // Set *default* container specific settings.json values on container create. "settings": {}, // Add the IDs of extensions you want installed when the container is created. "extensions": [] // Use 'forwardPorts' to make a list of ports inside the container available locally. // "forwardPorts": [], // Uncomment the next line to run commands after the container is created - for example installing curl. // "postCreateCommand": "apt-get update && apt-get install -y curl", // Uncomment when using a ptrace-based debugger like C++, Go, and Rust // "runArgs": [ "--cap-add=SYS_PTRACE", "--security-opt", "seccomp=unconfined" ], // Uncomment to use the Docker CLI from inside the container. See https://aka.ms/vscode-remote/samples/docker-from-docker. // "mounts": [ "source=/var/run/docker.sock,target=/var/run/docker.sock,type=bind" ], // Uncomment to connect as a non-root user if you've added one. See https://aka.ms/vscode-remote/containers/non-root. // "remoteUser": "vscode" } コンテナの設定を変更した時 Dockerfileを変更した時などは、リビルドを行います。 コンテナを起動した状態で左下の緑を選択するとこちらの選択肢が表示されますので、「Rebuild Container」を選択してください。 コンテナのコネクション切断と再接続 コンテナを起動した状態で左下の緑を選択した後の画面をスクロールし、「Close Remote Connection」でコネクションが切れプロジェクトが閉じます。 この時、コンテナも停止しします。(わかりづらいですが、今回NAMES「modest_chatelet」のコンテナを利用しており、ないことがわかります) 再度コネクションするには、再度左下の緑を選択して、「Open Folder in Container」を選択し、先ほどまでコネクションしていたプロジェクトを選択します。 つながりました。 その他 REMOTE EXPLORERにて、右クリック「Stop Container」を選択すると、停止後リロードを要求され、リロード後即起動されて停止することはできません。 この挙動は、ローカルのターミナルから停止コマンドを実行しても同様でした。 再接続の挙動でもVSCodeでContainer接続可能なプロジェクトを開いた瞬間勝手にコネクションされていましたのでそのVSCodeを開いている限り停止はできないと思います。 せっかくなのでコンテナを削除したらどうなるかみておきます。 一度、「modest_chatelet」のコンテナを削除します。 その後、左下の緑を選択して、「Open Folder in Container」を選択し、先ほどまでコネクションしていたプロジェクトを選択します。 ビルドが走り、勝手にコネクションされました。NAMESは「competent_allen」となり新しいコンテナで起動しています。 また、コネクション切断をせずにVSCodeを終了させるとコンテナは起動し続けます。 おわりに 簡単にDockerでの開発ができるようになったのでこれから、Webアプリを作ろうと思います。 ここまで、読んでいただきありがとうございました。 参考 今回は、以下サイトを参考にさせていただきました。 Developing inside a Container Dockerで立ち上げた開発環境をVS Codeで開く! Visual Studio CodeのRemote DevelopmentとDockerで快適な開発環境をゲット
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【サーバ構築練習】Mac + Docker + CentOS8

普段、サーバ構築の練習にはEC2を利用しています。 しかし、コンソール画面にログインするのが億劫になってきました。 そこで、ローカルで手軽にサーバ構築できないかと調べました。 結果、Mac + Docker + CentOSでなんとかなりそうなので、 その手順を自分用にまとめます。 Dockerインストール まずはDockerをインストール。 https://docs.docker.com/docker-for-mac/install/ 次にDocker Hubのアカウントを作成します。 https://hub.docker.com/ Dockerアプリを起動し、 先ほど作成したアカウントでログインしておきます。 あとはターミナルから操作していきます。 イメージをプル 以下のコマンドでCentOS8のイメージを取得します。 docker pull centos:centos8 イメージが取得できたことを確認します。 docker images コンテナを生成 + 起動 以下のコマンドでCentOS8のコンテナ(hogemoge)を生成し、起動します。 docker run --detach --name hogemoge --privileged --publish=8080:80 centos:centos8 /sbin/init 上記設定では、ホストの8080番ポートをコンテナ内の80番ポートに転送しています。 例えば、コンテナ内でApacheをインストールした場合、ブラウザで次のようにアクセスすれば、コンテナ内のApacheに繋がります。 http://localhost:8080 コンテナにログイン 以下のコマンドでコンテナ(hogemoge)にログインします。 docker exec -it hogemoge bash これで、Dockerを用いてサーバ構築の練習ができるようになりました。 その他コンテナ操作 コンテナからログアウトする時は以下のコマンド。 exit 起動中のコンテナ一覧 docker ps 全てのコンテナ一覧 docker ps -a コンテナの停止 docker stop hogemoge コンテナの起動 docker start hogemoge ちなみに、CentOS8ではyumコマンドではなくdnfコマンドを利用するみたいです。 また、自身でイメージを作成し、Docker Hubにプッシュしておくことで、いつでもその時の環境を再現することができるようなので、色んなサーバのテンプレートを用意するのも面白そうだなと思っています。 参考資料
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【まさかの半日でできる】AWS EC2からHerokuにサーバー移行する方法

はじめに ポートフォリオでAWSでデプロイしたが、Herokuに移行したいという人も多いかと思います。 こちらの記事で紹介したwebアプリをaws ec2にdockerを使って、デプロイをしていたのですが、 無料期間にもかかわらず、200円くらい料金がかかる ちょこちょこオチていた Herokuに移行することにしました。 かかった時間は以外にも1日くらいと、結構スムーズにできました。 ざっくりとですが、備忘録がてら自分が移行作業でやったことを載せます。 herokuにアプリをデプロイ まず、AWSにデプロイしていたアプリをherokuにデプロイします。 Dockerfileやdocker-compose.ymlを変える必要があると思いますので、適宜変えてください。 ちなみに私はこんな感じでHerokuにデプロイしたと思います。 docker-compose.yml version: "3" services: db: image: postgres ports: - '5432:5432' volumes: - ./tmp/db:/var/lib/postgresql/data environment: POSTGRES_PASSWORD: password web: build: context: . dockerfile: Dockerfile command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'" tty: true stdin_open: true depends_on: - db ports: - "3000:3000" volumes: - .:/my_app docker-compose.yml FROM ruby:2.7 RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - \ && echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list RUN apt-get update -qq && apt-get install -y nodejs postgresql-client yarn vim RUN mkdir /my_app WORKDIR /my_app COPY Gemfile /my_app/Gemfile COPY Gemfile.lock /my_app/Gemfile.lock RUN bundle install COPY . /my_app COPY entrypoint.sh /usr/bin/ RUN chmod +x /usr/bin/entrypoint.sh ENTRYPOINT ["entrypoint.sh"] EXPOSE 3000 CMD ["rails", "server", "-b", "0.0.0.0"] ローカルでdocker compose up -dしたら、 Herokuにデプロイしていきます。 ## コンテナにログイン heroku container:login ## tsumiki-appというアプリを作成 heroku create tsumiki-app ## tsumiki-appというアプリにコンテナをpush heroku container:push web --app tsumiki-app ## postgresを追加 heroku addons:create heroku-postgresql:hobby-dev --app tsumiki-app ## tsumiki-appをrelease heroku container:release web --app tsumiki-app heroku>アプリ>settingで環境変数を定義 RAILS_ENV: production RAILS_SERVE_STATIC_FILES: true SECRET_KEY_BASE: [value] # S3を使っている人はS3のいろいろも追加 $heroku config:get --- みたいにしても設定できますが、疲れてたのでheroku上でやりました(実はコマンド苦手意識) 参考 つづいて、migrateとprecompileをします。 heroku run rails db:migrate --app tsumiki-app heroku run rails assets:precompile --app tsumiki-app アプリをオープン heroku open --app tsumiki-app 無事デプロイできたかと思いましたら、 blocked hostとでたので、それを解消します。 config/application.rbに下記を追加。 config.hosts << "tsumiki-app.herokuapp.com" dbをdumpし、dumpファイルを作る 続いて、dumpファイルを作ります。 AWSで動かしていたpostgresのdb情報をdumpして、先程作ったherokuアプリに流し込みます。 ec2上にいって、下記を実行します。 /usr/local/src/postgresql-12.5/src/bin/pg_dump/pg_dump -U postgres -h `host` -p 5432 `database` -f aws0801.dump ローカルに持ってきます。 scp -i (.pem) myuser@ip-address:(ec2上の持ってきたいdumpがある場所) (dumpを持ってきたいローカルのパス) dumpとかscpとかよくわからない方は調べたら後々幸せになれます。笑 dumpファイルをherokuアプリに流す 流し方は、Heroku推奨のやり方でやってみました↓ s3からHerokuにアップロードする S3にダンプをアップロードして、Herokuにアップロードするやり方が推奨されてました。 すみません。これは頑張ってもできなかったのと、海外のサイトでも、できた人いないっぽかったので、おすすめしません。 直接流す。 heroku pg:psql --app tsumiki-app DATABASE_URL < aws0801.dump まさかのこれでできました。笑 cloudflareでssl化する 最後に、お名前ドットコムでとった、ドメインに、Herokuの方のドメインを紐付けます。 これで無料でssl化することができます。 下記を読めば簡単にできると思います。 詰まったところ 上記で、SSLをフルにしないと、ページが開けません。 フレキシブルにしていたので、開けませんでした。 それでは、お気をつけていってらっしゃい。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【半日でできる】AWS EC2からHerokuにサーバー移行する方法

はじめに ポートフォリオでAWSでデプロイしたが、Herokuに移行したいという人も多いかと思います。 こちらの記事で紹介したwebアプリをaws ec2にdockerを使って、デプロイをしていたのですが、 無料期間にもかかわらず、200円くらい料金がかかる ちょこちょこオチていた Herokuに移行することにしました。 かかった時間は以外にも1日くらいと、結構スムーズにできました。 ざっくりとですが、備忘録がてら自分が移行作業でやったことを載せます。 herokuにアプリをデプロイ まず、AWSにデプロイしていたアプリをherokuにデプロイします。 Dockerfileやdocker-compose.ymlを変える必要があると思いますので、適宜変えてください。 ちなみに私はこんな感じでHerokuにデプロイしたと思います。 docker-compose.yml version: "3" services: db: image: postgres ports: - '5432:5432' volumes: - ./tmp/db:/var/lib/postgresql/data environment: POSTGRES_PASSWORD: password web: build: context: . dockerfile: Dockerfile command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'" tty: true stdin_open: true depends_on: - db ports: - "3000:3000" volumes: - .:/my_app docker-compose.yml FROM ruby:2.7 RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - \ && echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list RUN apt-get update -qq && apt-get install -y nodejs postgresql-client yarn vim RUN mkdir /my_app WORKDIR /my_app COPY Gemfile /my_app/Gemfile COPY Gemfile.lock /my_app/Gemfile.lock RUN bundle install COPY . /my_app COPY entrypoint.sh /usr/bin/ RUN chmod +x /usr/bin/entrypoint.sh ENTRYPOINT ["entrypoint.sh"] EXPOSE 3000 CMD ["rails", "server", "-b", "0.0.0.0"] ローカルでdocker compose up -dしたら、 Herokuにデプロイしていきます。 ## コンテナにログイン heroku container:login ## tsumiki-appというアプリを作成 heroku create tsumiki-app ## tsumiki-appというアプリにコンテナをpush heroku container:push web --app tsumiki-app ## postgresを追加 heroku addons:create heroku-postgresql:hobby-dev --app tsumiki-app ## tsumiki-appをrelease heroku container:release web --app tsumiki-app heroku>アプリ>settingで環境変数を定義 RAILS_ENV: production RAILS_SERVE_STATIC_FILES: true SECRET_KEY_BASE: [value] # S3を使っている人はS3のいろいろも追加 $heroku config:get --- みたいにしても設定できますが、疲れてたのでheroku上でやりました(実はコマンド苦手意識) 参考 つづいて、migrateとprecompileをします。 heroku run rails db:migrate --app tsumiki-app heroku run rails assets:precompile --app tsumiki-app アプリをオープン heroku open --app tsumiki-app 無事デプロイできたかと思いましたら、 blocked hostとでたので、それを解消します。 config/application.rbに下記を追加。 config.hosts << "tsumiki-app.herokuapp.com" dbをdumpし、dumpファイルを作る 続いて、dumpファイルを作ります。 AWSで動かしていたpostgresのdb情報をdumpして、先程作ったherokuアプリに流し込みます。 ec2上にいって、下記を実行します。 /usr/local/src/postgresql-12.5/src/bin/pg_dump/pg_dump -U postgres -h `host` -p 5432 `database` -f aws0801.dump ローカルに持ってきます。 scp -i (.pem) myuser@ip-address:(ec2上の持ってきたいdumpがある場所) (dumpを持ってきたいローカルのパス) dumpとかscpとかよくわからない方は調べたら後々幸せになれます。笑 dumpファイルをherokuアプリに流す 流し方は、Heroku推奨のやり方でやってみました↓ s3からHerokuにアップロードする S3にダンプをアップロードして、Herokuにアップロードするやり方が推奨されてました。 すみません。これは頑張ってもできなかったのと、海外のサイトでも、できた人いないっぽかったので、おすすめしません。 直接流す。 heroku pg:psql --app tsumiki-app DATABASE_URL < aws0801.dump まさかのこれでできました。笑 cloudflareでssl化する 最後に、お名前ドットコムでとった、ドメインに、Herokuの方のドメインを紐付けます。 これで無料でssl化することができます。 下記を読めば簡単にできると思います。 詰まったところ 上記で、SSLをフルにしないと、ページが開けません。 フレキシブルにしていたので、開けませんでした。 それでは、お気をつけていってらっしゃい。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

ラズパイ4を買ったのでからあげ本をやってみた その1

重い腰をあげてようやくラズパイ4を購入したので、機械学習をやろうと思い、からあげ本をやってみたときの備忘録です。 環境は以下になります。 OS:ubuntu 20.04 docker:20.10.7 ラズパイ4 メモリ8GB web camera: Logitech C270 OSは etcher で焼いて使用しています。 https://www.balena.io/etcher/ 作成したものはコチラ にあります。 docker イメージもdocker hubにはpushしてあります。 docker をインストール 自分の場合は基本的にクリーンな環境でやりたいこともあるのですが、セットアップにあれこれ時間がかかるのはどうだろうなぁということと、インストール手順とか忘れてしまうのでコードで残せるように基本的にdockerを使って色々やっています。 ubuntuの場合、一番簡単なのは以下かなぁと思っていつも最初に実行してインストールします。 $ curl -L https://get.docker.com | sudo bash dockerイメージの作成 現状tensorflowのバージョンとしては2.5.0が最新っぽいのでコレを使用します。 tensorflowのページを見ながらビルドもしてみたのですが、うまくいかなかったので 最終的には @PINTO さんの使用させていただきました。 感謝です!! https://github.com/PINTO0309/Tensorflow-bin 2.5.0 のものは↓を使用しました。 https://github.com/PINTO0309/Tensorflow-bin/blob/main/tensorflow-2.5.0-cp38-none-linux_aarch64_download.sh コチラを使用したDockerfileは以下になります。 FROM ubuntu:20.04 ENV WORKUSER jupyter ARG LOCALUID=1000 ARG LOCALGID=1000 ARG DEBIAN_FRONTEND=noninteractive RUN apt update \ && apt upgrade -y \ && groupadd --gid $LOCALGID $WORKUSER \ && useradd --uid $LOCALUID --gid $WORKUSER --shell /bin/bash --create-home $WORKUSER \ && gpasswd -a $WORKUSER video \ && apt install -y \ curl \ cython3 \ gcc \ gfortran \ git \ libatlas-base-dev \ libatlas-base-dev \ libatlas3-base \ libblas-dev \ libc-ares-dev \ libeigen3-dev \ libgfortran5 \ libhdf5-dev \ liblapack-dev \ libopenblas-base \ libopenblas-dev \ libopencv-dev \ libopenmpi-dev \ openmpi-bin \ python3-dev \ python3-pip \ tmux \ vim \ v4l-utils\ && apt-get clean \ && rm -rf /var/lib/apt/lists/* WORKDIR /home/$WORKUSER USER $WORKUSER RUN pip3 install pip --upgrade \ && curl -LO "https://raw.githubusercontent.com/PINTO0309/Tensorflow-bin/main/tensorflow-2.5.0-cp38-none-linux_aarch64_download.sh" \ && bash ./tensorflow-2.5.0-cp38-none-linux_aarch64_download.sh \ && pip3 install tensorflow-2.5.0-cp38-none-linux_aarch64.whl \ && pip3 install -U --user six==1.15.0 wheel mock \ && pip3 install pybind11 \ && pip3 install keras_applications==1.0.8 --no-deps \ && pip3 install keras_preprocessing==1.1.0 --no-deps \ && pip3 install -U pandas \ && pip3 install -U numpy==1.20.3 \ && pip3 install -U opencv-python \ && pip3 install -U jupyterlab \ && pip3 install -U matplotlib \ && pip3 install -U scipy \ && pip3 install -U sklearn \ && pip3 install -U seaborn \ && rm tensorflow-2.5.0-cp38-none-linux_aarch64.whl \ && rm tensorflow-2.5.0-cp38-none-linux_aarch64_download.sh \ && rm -rf ~/.cache/pip COPY ./jupyterlab/entrypoint.sh /entrypoint.sh ENTRYPOINT ["/entrypoint.sh"] CMD ["jupyter", "lab", "--ip=0.0.0.0", "--no-browser"] 基本的には、Example of Python 3.x + Tensorflow v2 seriesをベースにDockerfileを作成していたのですが、作成するときにも色々手こずりました。 躓いたところを以下に書いていきたいと思います。 python公式の3.8系のdockerイメージだと何故かインストールに失敗する 最初はpython公式の3.8系のdockerイメージをベースにパッケージをインストールしていけばいいと思っていたのですが、どうもうまくいきません。 ちゃんと調べれてないですけど、@PINTO さんのところでも、tensorflow-2.5.0-cp38-none-linux_aarch64.whl はubuntu 20.04 と書いてあるので、python公式のdockerイメージはdebian busterなのでだめだったのかも。 tensorflow-2.5.0-cp38-none-linux_aarch64.whlを入れるとnumpyが1.19のバージョンになる tensorflow-2.5.0-cp38-none-linux_aarch64.whlを入れるとnumpyのバージョンが1.19.5 が入ります。 ですが、動かすためには1.20系をインストールする必要があるようです。 そのため、最初にtensorflow-2.5.0-cp38-none-linux_aarch64.whl をインストールし、その後1.20.3のバージョンのnumpyをインストールするようにしています。 webカメラがOpenCV で開けない これは、うーんと悩んでたんですけど、よくよく考えてみると、作成したjupyterユーザがvideoグループに属していないためでした。(たぶん) なので、作成したjupyterユーザをvideoグループに追加しています。 まとめ これでようやくラズパイ上で機械学習ができるようになりました。 docker化したので、とりあえずdockerだけ入れておけばサクッとお試しで動かせるようにできたかなと思います。 まだ、からあげ本のチャプター2の1しか試せていないので、ほかも試していきたいと思います。 jupyterlab 上でwebカメラをリアルタイムで表示するのってどうするんだろう。。。 ここまでお付き合いしていただきありがとうございます。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む