What's New Qiita

20200629のdockerに関する記事は8件です。

  • 投稿日：2020-06-29T22:41:52+09:00

【Docker入門】Deno環境をDockerで構築する??

はじめに

※ Docker入門者の学習記事です！

Deno が盛り上がって来ているように見えます。?

興味をそそられたので、学習も兼ねてさっそくDockerでコンテナ化してみました。

以下からクローンも可能です。

https://github.com/ShinKano/deno-docker

ゴール

  • Dockerfileを自作して、イメージを作ってみる
  • コンテナにDenoをインストールして、触れる環境を作る
  • Denoの標準APIを使用して、Webサーバーを立ち上げる

Dockerfileを作成

コンテナイメージの元となるDockerfileを作成します。

最終的には、以下のようなものが出来上がりました。

FROM debian:stable-slim

WORKDIR /var/www/html

RUN apt-get -qq update \
  && apt-get -qq -y install curl zip unzip \
  && curl -fsSL https://deno.land/x/install/install.sh | sh \
  && apt-get -qq remove curl zip unzip \
  && apt-get -qq remove --purge -y curl zip unzip \
  && apt-get -qq -y autoremove \
  && apt-get -qq clean \
  && echo 'export DENO_INSTALL="/root/.deno"' >> ~/.bash_profile \
  && echo 'export PATH="$DENO_INSTALL/bin:$PATH"' >> ~/.bash_profile

CMD ["/bin/bash", "-c", "source ~/.bash_profile && bash"]

Dockerfileの内容

基本設定

元となるOSイメージ: 今回は軽量なdebian-slimを選択

FROM debian:stable-slim

今回はWebサーバーを起動させるので、/var/www/htmlを作業ディレクトリに指定してみました。

WORKDIR /var/www/html

Denoのインストール

基本的には、Deno公式のやり方と同じです。

まずは、Denoのインストールと、シェルスクリプトの実行に必要なcurl zip unzipをインストールします。

RUN apt-get -qq -y install curl zip unzip

Deno公式のやり方と同じようにインストールコマンドを実行。

RUN curl -fsSL https://deno.land/x/install/install.sh | sh

あとしまつ

不要なファイルを削除します。

—purgeオプションを使用すると設定ファイルごとすべて削除します。再び使わないようなパッケージに使用。

RUN apt-get -qq remove --purge -y curl zip unzip

不要になった依存パッケージまで削除

RUN apt-get -qq -y autoremove

パスを通す

denoコマンドを使用するために、パスを通してやる必要があります。

RUN echo 'export DENO_INSTALL="/root/.deno"' >> ~/.bash_profile \
  && echo 'export PATH="$DENO_INSTALL/bin:$PATH"' >> ~/.bash_profile

たった今変更したプロファイルを、bashに適用します。

CMDにはコンテナ起動直後に実行されるコマンドを記述します。

コンテナ起動後も引き続きbashを使用するので、最後に&& bashを引っ付けておきました。

CMD ["/bin/bash", "-c", "source ~/.bash_profile && bash"]

イメージのビルド

-tオプションをつけることで、名前をつけてイメージをビルドします。今回はdeno-dockerと名付けました。

Dockerfileを作ったディレクトリで、以下のコマンドを実行します。

docker build ./ -t deno-docker

コンテナの起動

以下のコマンドで、コンテナを起動します。

ちょっと長いですが...

docker container run -it --rm -p 8080:8080 --mount src=`pwd`,target=/var/www/html,type=bind --disable-content-trust deno-docker

１行づつコメントを以下につけました。

docker container run \ # コンテナ起動
-it \ # コンテナに入って標準入力を待ち受ける
-p 8080:8080 \ # ポートの指定（ホストのポート：コンテナのポート）
--rm \ # コンテナを停止したら自動でコンテナ廃棄する
--mount src=`pwd`,target=/var/www/html,type=bind\ # バインドマウント
--disable-content-trust\ # 証明書のないイメージを信頼する
deno-docker # 先ほど作成したイメージ

DenoでWebサーバーを立ち上げる

コチラも公式チュートリアルのまんまです。

詳しい解説は、公式から確認できます。

helloDeno.ts
import { serve } from "https://deno.land/std@0.50.0/http/server.ts";

const s = serve({ port: 8080 }); // さっきコンテナに指定したポート
console.log("http://localhost:8080/");

for await (const req of s) {
  req.respond({ body: "<h1>Hello Deno</h1>\n" });
}

  • Denoは標準でTypescriptをサポートしています！ 面倒な設定ともオサラバ？✋

  • asyncなしで、awaitが使用可能です！

denoコマンドで実行する

先ほどバインドマウントしたディレクトリに、Typescriptファイル（今回はhelloDeno.ts）を保存し、
以下のコマンドを実行します。

deno run --allow-net helloDeno.ts

Denoは標準でファイル、ネットワーク、環境変数等にアクセスすることができないセキュアな設定になっています。

ネットワークを許可するには--allow-netオプションを付与して実行します。

スクリーンショット 2020-06-29 22.37.40.png

見事、Webサーバーが起動できました！

まとめ

  • Dockerfileを自作して、イメージを作ることができた
  • コンテナにDenoをインストールして、（少しだけど）Denoプログラムを書けた
  • Denoの標準APIを使用して、Webサーバーを立ち上げた

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-06-29T20:27:13+09:00

docker-compose upの直後Yarnのエラーでコンテナが落ちる問題と解決

環境

MacOS Mojave: 10.14.6
Docker: 19.03.8
Ruby: 2.6.6
Rails: 6.0.0
PostgreSQL

問題

RailsチュートリアルのSample_appを
Docker環境に移行している途中で

docker-compose upのあとpumaが起動した後すぐに以下のエラーを吐いて落ちる現象に遭遇

warning Integrity check: System parameters don't match
app_1  | error Integrity check failed
app_1  | error Found 1 errors.
app_1  | 
app_1  | 
app_1  | ========================================
app_1  |   Your Yarn packages are out of date!
app_1  |   Please run `yarn install --check-files` to update.
app_1  | ========================================
app_1  | 
app_1  | 
app_1  | To disable this check, please change `check_yarn_integrity`
app_1  | to `false` in your webpacker config file (config/webpacker.yml).
app_1  | 
app_1  | 
app_1  | yarn check v1.22.4
app_1  | info Visit https://yarnpkg.com/en/docs/cli/check for documentation about this command.

config/webpacker.ymlを編集する解決方法が見つかったがこれでは解決せず
yarnが原因でdocker-compose runが実行できないときの対処法 - Qiita

解決

こちらを参考にconfig/environments/development.rbとconfig/webpacker.ymlを編集して解決しました
Running a Rails app with Webpacker and Docker - Dirk de Kok - Medium

Last configuration for Yarn and Webpacker

Rails does a lot of checkups on Yarn, a bit too much. Best is to disable this:

# config/environments/development.rb
config.webpacker.check_yarn_integrity = false

Also, we need to tell Rails that the webpacker server is running on the host webpacker and enable hot module reload. So set these values:

# config/webpacker.yml
development:
  dev_server:
    host: webpacker
    hmr: true

Last configuration for Yarn and Webpacker

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-06-29T18:55:27+09:00

【php-fpm,nginx,mysql】docker-composeで開発環境を構築する

dockerで開発環境を構築する際の手順

お断り

エンジニアとしてまだまだ未熟なので、
色々と間違っている場合もあるかもしれませんので、その場合は、コメントなどでご指摘いただけると嬉しいです!
知識のブラッシュアップにご協力お願いします！

説明する技術

  • docker
  • docker-compose

dockerとは

dockerを使えば、自分のpcの中に仮想コンテナを作成できるよってツールです。他にも仮想環境構築のためのツールは存在しますが、dockerは手軽さがウリ！だと思っています！簡単に仮想環境作ったり、消したり、更新したりが可能です。こちらの記事など参照にしたのでよくわからない方は是非ご覧ください。今回はコマンドなどではdocker-composeを利用していますが、基盤はdockerです。

docker-composerとは

簡単に説明すると以下のイメージです。
dockerコンテナを操作する"docker"コマンドはdockerコンテナ一つ一つを操作するためのコマンドですが、"docker-compose"コマンドは複数のdockerコンテナの相関関係を定義し、一括操作するためのコマンドです。dockerコンテナの複数管理用コマンドって感じですね
。
2020-06-22 18.38.25.png

ディレクトリ構成

関係ないファイルは表示していませんが基本的な構造はこんな感じです。一部フォルダ名とかは見やすいように修正してます。

Directory
PROJECT-NAME
├── Api
│   ├── docker-compose.yml
│   ├── docker-mysql
│   │   ├── Dockerfile
│   │   ├── conf
│   │   │   └── my.cnf
│   │   └── data
│   │   　　   └── 'dbのデータファイル群（DBのスキーマ構造とかデータとかの自動で作られるファイル）'
│   ├── docker-nginx
│   │   ├── Dockerfile
│   │   └── nginx.conf
│   ├── docker-php
│   │   └── Dockerfile
│   └── project
│       └── ..
└── Front
    ├── Dockerfile
    ├── docker-compose.yml
    ├── docker-nginx
    │   ├── default.conf
    │   └── log
    └── project
        ├── ..

【Api側】Dockerfile

各dockerコンテナの設定ファイルです。

php-fpmのDockerfile

php側では、必要なphpのライブラリとかをinstallするコマンド書いてあげます。初心者目線でのポイントは、FROMで指定したdockerイメージのOSの種類に合わせたコマンドをしっかり調べて書くことです。今回は"php:7.3-fpm"というdockerhubで公開されているphp公式イメージのphp-fpmを使いました。どうやらこいつがDebian系だったので、Dockerfileの中でapt-getコマンドを使ってます。

Api/docker-php/Dockerfile
# 基盤のimageファイル選択（php公式イメージ）
FROM php:7.3-fpm
# コンテナを立ち上げるときにライブラリ・パッケージのアップデートとインストール
RUN apt-get update && apt-get install -y \
  vim \
  zip \
  unzip \
  iputils-ping \
  git \
  imagemagick \
  gcc \
  make \
  libpng-dev \
  libmcrypt-dev \
  libjpeg-dev \
  libfreetype6-dev \
  && docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/ \
  && docker-php-ext-install -j$(nproc) gd

# コンテナを立ち上げるときにPDOのインストール（API作成前のDB接続確認のためインストール）
RUN docker-php-ext-install pdo_mysql

# composerファイルのコピー（APIでLaravel使うので、composerの準備もしておく）
COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

# 作業ディレクトリの指定（dockerコンテナに接続した時どのディレクトリから開始するか）
WORKDIR /var/www/html/project

nginxのDockerfile

nginx公式イメージを使用しました。vimとかunzipとか必要そうなミドルウェアを追加してます。

Api/docker-nginx/Dockerfile
# 基盤のimageファイル選択（nginx公式イメージ）
FROM nginx:1.17.9
# コンテナを立ち上げるときにパッケージのアップデートとインストール
RUN apt-get update && apt-get install -y \
  vim \
  unzip \
  zip \
  git

# 作業ディレクトリの指定
WORKDIR /var/www/html

mysqlのDockerfile

ここでは特に指定せず。mysqlの設定ファイルを別で作成しました。イメージはmysql公式イメージを利用しました。

Api/docker-mysql/Dockerfile
# 基盤のimageファイル選択
FROM mysql:8.0.19

【Front側】Dockerfile

ここもApi側と一緒ですね。ApiとFrontでwebサーバを分けたのはマイクロサービス化したかったからです！あんまりわかっていないですが！一緒でもよかったのかなとか後から思いました。

Front/Dockerfile
# -----------------------------------------------------------------
# Nginx
# -----------------------------------------------------------------
# 基盤のimageファイル選択
FROM nginx:1.17.9
# コンテナを立ち上げるときにパッケージのアップデートとインストール
RUN apt-get update && apt-get install -y \
  vim \
  unzip \
  zip \
  git

【Api側】docker-compose.yml

Api/docker-compose.yml
version: "3"

services:
    # webサーバ用コンテナ設定
    web:
        # 元となるDockerfileのディレクトリ
        build: ./docker-nginx
        # コンテナ名を明示的に指定する
        container_name: API_Web_Container
        # 他コンテナとの依存関係（コンテナ起動の順番にも関係）
        depends_on:
            - app
        ports:
            - 80:80
        # マウントするホスト側ディレクトリ:マウント先コンテナディレクトリ
        volumes:
            - ./project/lib:/var/www/html/project
            - ./docker-nginx/nginx.conf:/etc/nginx/conf.d/default.conf
        # 他サービスとの接続
        links:
            - app
        # 継続起動のため
        tty: true
    # アプリケーションサーバ設定
    app:
        # 元となるDockerfileのディレクトリ
        build: ./docker-php
        # コンテナ名を明示的に指定する
        container_name: App_Container
        # 他コンテナとの依存関係（コンテナ起動の順番にも関係）
        depends_on:
            - db
        # 他サービスとの接続
        links:
            - db
        # マウントするホスト側ディレクトリ:マウント先コンテナディレクトリ
        volumes:
            - ./project/lib:/var/www/html/project
        # 継続起動のため
        tty: true
    # DBサーバ設定
    db:
        # 元となるDockerfileのディレクトリ
        build: ./docker-mysql
        # コンテナ名を明示的に指定する
        container_name: DB_Container
        ports:
            - 3306:3306
        # DBの変数設定
        environment:
            MYSQL_ROOT_PASSWORD: XXXXX #ここにroot用のパスワードを記載
            MYSQL_DATABASE: XXXXX #ここにデータベースを記載
            MYSQL_USER: XXXXX #ここにユーザ名を記載
            MYSQL_PASSWORD: XXXXX #ここにユーザ用パスワードを記載
        # マウントするホスト側ディレクトリ:マウント先コンテナディレクトリ
        volumes:
            # mysqlの設定ファイルをコンテナにマウント（ミラーリング的な？）
            - ./docker-mysql/conf:/etc/mysql/conf.d
            # 永続化するときにマウントするdir
            - ./docker-mysql/data:/var/lib/mysql

【Front側】docker-compose.yml

Front/docker-compose.yml
version: '3'

services:

 # webサーバ用コンテナ設定
 front:
    # 元となるDockerfileのディレクトリ
    build: .
    # コンテナ名を明示的に指定する
    container_name: Front_Web_Container
    ports:
        - 8080:8080
    # 継続起動のため
    tty: true
    networks: 
        - api_default
    # マウントするホスト側ディレクトリ:マウント先コンテナディレクトリ
    volumes:
        - ./docker-nginx/log/:/var/log/nginx/
        - ./project/build:/var/www/html/project
        - ./docker-nginx/default.conf:/etc/nginx/conf.d/default.conf
# APIのネットワーク名
networks: 
 api_default: // APIとFRONTのdockerコンテナ群をつなげるネットワーク
    external: true

dockerコンテナのビルド（*設計図に変更がなければ初回だけでOK）

dockerコンテナの*設計図（Dockerfileとdocker-compose.yml）を元に仮想コンテナを作成する。
docker-compose.ymlがある階層で以下のコマンドを実行します。ビルドがうまく行かない場合は各Dockerfileを見直してください。 2020-06-29 18.45.58.png

$ docker-compose build --no-cache    // --no-cacheはオプション

ビルドしたコンテナの起動

dockerコマンドと違ってportの指定など細かい設定をコマンドで記載する必要がないのがdocker-composeのいいところ！docker-compose.ymlがある階層で以下のコマンドを実行します。

$ docker-compose up -d

doneで起動成功していたらOK、失敗したらエラーメッセージを確認して見てください。

pc-user@pc-name api % docker-compose up -d
Starting DB_Container ... done
Starting App_Container ... done
Starting API_Web_Container ... done

起動がうまく行かない場合はdocker-compose.ymlを見直してください。

起動確認

コンテナが正常に起動できるか確認します。docker-compose.ymlがある階層で以下のコマンドを実行します。

$ docker-compose ps

pc-user@pc-name api % docker-compose ps
  Name               Command                         State   Ports
------------------------------------------------------------------------------------
App_Container       docker-php-entrypoint php-fpm   Up      9000/tcp
DB_Container        docker-entrypoint.sh mysqld     Up      0.0.0.0:3306->3306/tcp, 33060/tcp
API_Web_Container   nginx -g daemon off;            Up      0.0.0.0:8086->80/tcp

テーブル構造見やすいですね〜
StateがUp以外の場合は、起動後コンテナが停止してしまっているので継続起動の設定部分を確認してみてください。

API側でdocker-composeコマンドでコンテナをビルド・起動した場合はこのような結果となります。全てのコンテナが起動し、停止していなかったらOKです！問題が起こった場合は、docker-compose logsコマンドなどで原因を調査して、解決してください。

いい感じに起動したら最後に、、、！

dockerコンテナに接続

$ docker-compose exec app bash //appの部分はdocker-compose.ymlで定義したサービス名を入力
$ docker-compose exec web bash //appの部分はdocker-compose.ymlで定義したサービス名を入力
$ docker-compose exec db bash  //appの部分はdocker-compose.ymlで定義したサービス名を入力

念のため、3つのコンテナにそれぞれ接続するコマンドを記載しました。例として、DBに接続したい場合は、直接dockerコンテナに接続して、mysql -u -root -p（DBの種類に合わせて変更してください）と入力するか、GUIでDBに接続するツール等で127.0.0.1のIPと3306のポートを指定してあげれば大丈夫です！

2020-06-29 18.45.58.png

補足

上記のdocker-compose.ymlファイルの場合、API側のdockerコンテナ起動→Front側のコンテナ起動の順番で行ってください！理由は、ネットワークの構築をAPI側で行っているからです。もしFront側を先にdocker-compose upしようとすると、「ネットワークがないよ」と怒られるのでご注意ください。

終わりに

ここまで、自分のPC内でdocker,docker-composeを使って環境構築する例を記載しました！
自分は環境構築に2週間くらいかかった感じですが、初心者すぎました！笑

ある程度エンジニアとして働いているかたはさらっと3日以内でできると思いますのでぜひdockerを使ってみてください！

以上、手軽に開発環境が構築できるdocker大好きマンでした！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-06-29T13:35:43+09:00

psql コマンドは Docker コンテナとして実行しよう

ターミナルから psql コマンドを使って外部の PostgreSQL サーバに接続したいが、 psql コマンドを使うためには作業マシンに PostgreSQL をインストールしなければならない。

作業マシンに PostgreSQL をインストールすると何が起きるかというと、 createuser のような「PostgreSQL っぽくない名前のコマンド1」がインストールされてしまう。これがあまり好きではなく、この理由のため自分は作業マシンに PostgreSQL をインストールしたくない。

しかし、外部の PostgreSQL サーバと接続するために psql コマンドだけは使いたい。

こういうときは、Docker の出番である。

~/.bashrc
alias psql="docker run --rm -it --net=host postgres psql"

psql コマンドは Docker コンテナの中で動かすことにして、シェルの alias で普通の psql コマンドとして使えるようにしている。

※ --net=host はなくても構わないのだけど、これがあると同じ端末内の別の Docker コンテナで PostgreSQL サーバが動いていてポートがマッピングされている場合に「ホスト名 localhost」としてアクセスできるようになる。

コンテナ内に環境を閉じ込めることで psql 以外のコマンドはホスト側に露出することがなくなり、いい感じなった。

pg_dump や pg_restore が欲しくなった場合は alias を追加すれば良い。

AWS CLI もそう 2 だけど、コマンドを Docker コンテナの中に閉じ込めて実行するというスタイルは当たり前になっていくのかもしれない。

  1. PostgreSQLクライアントアプリケーション | PostgreSQL 12.0 ドキュメント ↩

  2. AWS CLI v2 Docker image | AWS Developer Blog ↩

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-06-29T12:17:42+09:00

[備忘録] [初心者] Docker Compose / Rails(公式doc.)について自分用補足#1 (Dockerfile, entrypoint.sh)

はじめに

背景

一次ソース(に出来るだけ近い情報)を参照しながら学習を進める訓練をしています。
また、これまでスルーしがちだった基礎用語や概念を深掘りする学習も始めました。

今回は、下記のチュートリアルを対象にします。
クィックスタート: Compose と Rails | Docker ドキュメント

Dockerfileとシェルスクリプトファイル(entrypoint.sh)についてまとめた時点で文量が多くなってしまったため、これら以外の内容については次回の投稿にまとめます。

英文はまずDeepLの機械翻訳文を読んでから解釈を試みています。

注意

本稿は、Dockerについて理解の無い私がメモとして記している物です。
単なる個人的な感想も多く、また、解釈文であっても間違いがある可能性があります。
本稿を勉強目的でご覧になる場合は、この本文ではなく参照リンク先の方をご覧いただければと思います。
(リンク集としては少しは役に立てるかも...)
また、常識的なITの基礎用語であっても、とにかく私自身が知らなかったものには反応しているため、冗長であったり、本筋から脱線したような内容が多くなっています。

本編

クィックスタート: Compose と Rails | Docker ドキュメント
こちらのチュートリアルを読み進めていきます。

Dockerfile全体

Dockerfile
FROM ruby:2.5
RUN apt-get update -qq && apt-get install -y nodejs postgresql-client
RUN mkdir /myapp
WORKDIR /myapp
COPY Gemfile /myapp/Gemfile
COPY Gemfile.lock /myapp/Gemfile.lock
RUN bundle install
COPY . /myapp

# コンテナー起動時に毎回実行されるスクリプトを追加
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"]

1行目 : FROM ruby:2.5

Dockerfile(1行目)
FROM ruby:2.5

FROM

FROM | Docker ドキュメント日本語化プロジェクト >> Docs
FROM命令の役割は、処理ステージの初期化と、ベースイメージの設定

まだ、現状の自分には概念理解が難しいと感じました。

とりあえず後日参考にしそうなリンクだけ...

今回はこのコンテナのベースイメージとして、RubyのDockerイメージを設定するということのようです。
ruby - Docker Hub

２行目 : RUN apt-get ...

Dockerfile(２行目)
RUN apt-get update -qq && apt-get install -y nodejs postgresql-client

RUN

RUN | Docker ドキュメント日本語化プロジェクト >> Docs
コマンドの実行

apt-getコマンドについて

APT(Application Packaging Tool)は、もともとDebian向けのパーケージ管理システムのことで、Debian系以外のディストリビューションでもそのコマンドを使用できる場合もあるようです。
Debianというのは、あるフリーのOSであって、apt-getはDebian系のOS上でパッケージを操作するためのコマンドのようです。

Debian について | Debian

Debian は、現在 Linux カーネルか FreeBSD カーネルを利用しています。

Linux カーネル?
About Linux Kernel | The Linux Kernel Archives

If you're new to Linux, you don't want to download the kernel, which is just a component in a working Linux system. Instead, you want what is called a distribution of Linux, which is a complete Linux system.

カーネルはあくまでLinuxシステムの様々な機能を担うコンポーネント(部品のような存在)であって、完全なLinuxシステムを手元で扱うのならば、出来合いのOSとして配布(或いは販売)されているDistribution of Linux（Linuxディストリビューション）が必要ということでしょうか。

https://mirrors.kernel.org/
このサイトで、代表的なディストリビューションのミラーが提供されているようです。
The Debian Linux distributionが提供されていることも確認できます。

Linuxディストリビューション | Wikipedia
Linuxカーネル | Wikipedia
公式版のカーネルは、ディストリビューションのベンダーにて独自にカスタマイズされていることもあるようです。

Linux豆知識 028 カーネル（kernel） | LPI-Japan

これはよく言われることですが、厳密には「Linux」と言った場合、このLinux kernelのことを指します（最近では、後述する「Linuxディストリビューション」をLinuxと呼ぶケースも増えてきています）。

"Linux"と記載されている場合でも、文脈によってLinuxカーネルだったり、ディストリビューションの事を指していたりするってことか。慣れていくしかなさそうです。

ここでapt-getコマンドの話に戻りますが、このコマンドが使用できるということは、RubyのDockerイメージは、Debian系のLinuxディストリビューションをベースにしているのでしょうか？

ruby - Docker Hub
Image Variants 項にて　ruby:＜version＞について

This tag is based off of buildpack-deps. buildpack-deps is designed for the average user of Docker who has many images on their system. It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system.

Rubyの標準Dockerイメージのベースとなっているbuildpack-depsは、ごく一般的なDebianのパッケージを大量に含んでいるらしく、この説明文から、RubyのDockerイメージ環境下でのパッケージ操作のためにapt-getコマンドを使用できそうな気はしてきます。
(上記引用文で言及されているDebianの一般的なパッケージ群？ -> buildpack-deps/Dockerfile.template)

ただ、使用するOSについての直接的な記述を見たいです。
Stack Overflowで質問を調べてみると、同様の疑問に関する質疑がありました。
node.js - Docker Hub - Node Repo - What OS is this running? - Stack Overflow
ベスト解答では、Dockerfileのベースイメージを辿れば答えに行き着くことが説明されています。

同様に探ってみます。
今回のベースイメージは、ruby:2.5なので、まずはそのバージョンのディレクトリへ。
https://github.com/docker-library/ruby/tree/master/2.5
/2.5以下の構成は、alpine3.11, alpine3.12, buster, stretchの4種類があり、alpineはLinuxディストリビューションのひとつである、Alpine Linux projectを指します。

ruby - Docker Hubにも記載の通り、busterやstretchは、Debianのスイート名です。
("スイート"という用語は今回が初見で、個々についてはスイートを成す派生品群のひとつという解釈をしています。間違えていたらすみません。 参照：アプリケーションスイートとは 「ソフトウェアスイート, スイート」 (application suite)： - IT用語辞典バイナリ)

ruby - Docker Hub > Supported tags and respective Dockerfile linksの項より、今回のようなタグなし(ruby:2.5)の場合は、buster用のDockerfileにサポートされているようなので、その内容を見ていきます。
https://github.com/docker-library/ruby/blob/master/2.5/buster/Dockerfile

ruby/2.5/buster/Dockerfile
FROM buildpack-deps:buster

ベースイメージとして、buildpack-deps:busterを指定しているようです。同様に辿ってベースイメージの記述を見ていきます。
https://github.com/docker-library/buildpack-deps/blob/master/debian/buster/Dockerfile

buildpack-deps/debian/buster/Dockerfile
FROM buildpack-deps:buster-scm

最終的に以下に行き着きました。
https://github.com/docker-library/buildpack-deps/blob/master/debian/buster/curl/Dockerfile

buildpack-deps/debian/buster/curl/Dockerfile
FROM debian:buster

これで、RubyのデフォルトのDockerイメージ上で稼働するOSがDebian系であることは確認できたので、apt-getコマンドが使用可能であることは腑に落ちました。

apt-get update -qq

apt-get(8) - Debian Manpages
update : 利用可能なパッケージの一覧を更新するようです。
-qq:進捗のログを省略し、また、含まれた-yによってプロンプトへ自動で'yes'を応答して進めるというもののようです。

下記の質疑によると、-qqオプションのみで実行してしまうと、システムに予期せぬ影響を及ぼす変更がある場合に、ログが出力されないために気づけないということが起こりうるので、安全管理面で使用には注意が必要なようです。
software installation - Why shouldn't I use apt-get install --qq without a no-action modifier? - Ask Ubuntu

apt-get install -y nodejs postgresql-client

開発の都合によっては、ここでYarnなども追記してインストールします。

Getting Started with Rails — Ruby on Rails Guides

3~8行目

Dockerfile(3~4行目)
RUN mkdir /myapp
WORKDIR /myapp

WORKDIR

WORKDIR | Docker ドキュメント日本語化プロジェクト >> Docs
ワークディレクトリを設定する。

Railsアプリケーションを置くフォルダを生成して、ワーキングディレクトリとして設定しています。

Dockerfile(5~8行目)
COPY Gemfile /myapp/Gemfile
COPY Gemfile.lock /myapp/Gemfile.lock
RUN bundle install
COPY . /myapp

COPY

COPY | Docker ドキュメント日本語化プロジェクト >> Docs
ファイルやディレクトリを新たにコピーして、対象のパスに追加する。

チュートリアルの手順として、ローカルにGemfileとGemfile.lockを生成するので、それらをコンテナ内のRailsアプリケーションを置くパスにコピーしています。

entrypoint.sh (シェルスクリプトファイル)

このチュートリアルではentrypoint.shというシェルスクリプトファイルを生成して使用します。
そもそも、シェルスクリプトの概念を知らなかったので、もまともに調べたのが今回初めてとなりました。

Bash - GNU Project - Free Software Foundation
The GNU Bourne-Again Shell
Bash Reference Manual
/bin/bashとは｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典

今回扱うシェルスクリプトファイルの内容は以下の通りです。

entrypoint.sh
#!/bin/bash
set -e

# Rails に対応したファイル server.pid が存在しているかもしれないので削除する。
rm -f /myapp/tmp/pids/server.pid

# コンテナーのプロセスを実行する。（Dockerfile 内の CMD に設定されているもの。）
exec "$@"

#!/bin/bash

１行目の#!/bin/bashについてはマニュアルに下記の説明があります。
3.8 Shell Scripts - Bash Reference Manual

If the first line of a script begins with the two characters ‘#!’, the remainder of the line specifies an interpreter for the program.

また、

Bash scripts often begin with #! /bin/bash (assuming that Bash has been installed in /bin), since this ensures that Bash will be used to interpret the script, even if it is executed under another shell.

つまり、#!/bin/bashはコメント文ではなく、#!によってインタプリタを/bin/bashに指定して、そのOSで使用されるシェルの系統に関わらずスクリプトを/bin/bashとして解釈し、処理を進めるという意味があるようです。
次行に処理のコードが続きます。

set -e

4.3.1 The Set Builtin - Bash Reference Manual
Bashの内部コマンドで、シェルのオプション値を変更したり、位置パラメータを設定する。
-eオプションの説明項

Exit immediately if a pipeline (see Pipelines), which may consist of a single simple command (see Simple Commands), a list (see Lists), or a compound command (see Compound Commands) returns a non-zero status.

上記解説で言うと、今回はどれも"a single simple command"なのでしょうか...?
また、ステータスがゼロの時と、ゼロでない時とは、それぞれ具体的にどのようなときを指すのでしょうか。

3.2.1 Simple Commands - Bash Reference Manual

It’s just a sequence of words separated by blanks, terminated by one of the shell’s control operators (see Definitions).

空白で区切られる場合や、制御演算子で終了する場合のこと。

2 Definitions - Bash Reference Manual
制御演算子の項に"改行"も含まれているので、entrypoint.shでset -e以降のコードは、それぞれSimple Commands(単純なコマンド？)に分類できると判断しました。

3.7.5 Exit Status - Bash Reference Manual

For the shell’s purposes, a command which exits with a zero exit status has succeeded. A non-zero exit status indicates failure.

上記引用のset -eの終了条件とは、終了ステータス
成功：0,
失敗：0以外
ということでしょうか。

set -eについて、実際の挙動を解説する動画もありました。(英語は分かりませんが...)
Learn about scripts, functions, chmod and set -e | #2 Practical Bash - YouTube
　5:22~あたりからset -e或いはset +eの挙動が実演されています。
　　set +e以降はステータスが0の場合に直ちに終了
　　set -e以降はステータスが1(0以外)の場合に直ちに終了
動画では関数内でreturnによってステータスの値を渡しています。

entrypoint.sh内では、いずれかのコマンドが失敗すれば、直ちにプロセスを終了するために先頭で呼ばれているようです。

rm -f /myapp/tmp/pids/server.pid

マニュアルのページは下記
rm(1) — Linux manual page

削除対象のPIDファイルについて
pidfile - What are pid and lock files for? - Unix & Linux Stack Exchange
起動中のプロセスIDを記録して、それが実行中であることを判断するために生成されているもののようです。

従って、実行状態の判断をPIDファイルに依存している場合は、サーバーの終了方法によってはPIDファイルが削除されずに残る場合があるため、今回はこのスクリプトファイル内で削除する一文を加えることで、コンテナサーバー起動前に毎回PIDファイルを削除するようにしているようです。
-fオプションによって、対象ファイルが存在しなかった場合もエラーは返しません。

後日参照したい

exec "$@"

4.1 Bourne Shell Builtins
execはBourne Shellから継承されてBashでも使用できるコマンドのひとつです。

@ - 3.4.2 Special Parameters - Bash Reference Manual

現時点では解説を読んでも理解し難かったので、手元で実行して比較しました。

  • ２番目の位置パラメータを指定($2)
hoge.sh
#!/bin/bash
echo "$2"

$ ./hoge.sh a b c d e
#=> b

配列のインデックスなどと違って、位置パラメータは数え番そのままの数値であることは注意したいです。

  • 位置パラメータを展開($@)
hoge.sh
#!/bin/bash
echo "$@"

$ ./hoge.sh a b c d e
#=> a b c d e

ここでの結論として、entrypoint.sh内で最後の行のコードexec "$@"の役割は、entrypoint.sh自体の親プロセスを展開したそれぞれの引数の実行結果に置き換えてコマンドラインへ出力し、entrypoint.shの実行以降の処理に進ませることであると思われます。

その他参考

脱線：manコマンド(macOSの場合)

調べる過程でmanページのことを初めて知りました。
macのターミナルで$ man rmを実行したらman7.orgにあったものと同様のものを読めました。
setやexecについては、manが適用できないのかと思いましたが、ふざけて実行すると、いずれもBUILTIN(1) - BSD General Commands Manualの内容が呼ばれました。
なんか違うOSの名前出てきた！と思ったらmacOSはFBDの血筋を引いている説明を見つけました。(BSD #BSDの主な子孫 - Wikipedia)

macでDarwinのバージョンを調べるコマンドがあったので確認してみました。

$ uname -v
Darwin Kernel Version 19.5.0: Tue May 26 20:41:44 PDT 2020; root:xnu-6153.121.2~2/RELEASE_X86_64

Darwin7.0からデフォルトのシェルをBashに変更したとあるので、manコマンドでBashのコマンドのマニュアル呼ぼうとしたらBSDのコマンドマニュアルが呼ばれるのも、そのあたりの関係性によるものなのでしょうか。

頭が付いていかないので、今回はこのあたりにしておきます。

10~17行目 コンテナの起動時

Dockerfile(10~17行目)
# コンテナー起動時に毎回実行されるスクリプトを追加
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"]
Dockerfile(11行目)
COPY entrypoint.sh /usr/bin/

チュートリアルの手順にて、ローカルで作成していたentrypoint.shをコンテナルート下/usr/bin/へコピーしています。

Dockerfile(12行目)
RUN chmod +x /usr/bin/entrypoint.sh

CHMOD(1) - BSD General Commands Manual
chmod - Wikipedia

全クラスに対して、(x)実行権限を(+)付与する
つまり、ユーザーに関わらず/usr/bin/entrypoint.shに実行権限を付与して、シェルスクリプトファイルを実行可能としています。

Dockerfile(13行目)
ENTRYPOINT ["entrypoint.sh"]

ENTRYPOINT

ENTRYPOINT | Docker ドキュメント日本語化プロジェクト >> Docs

今回では、exec形式にてデフォルトで実行するコマンドライン引数としてentrypoint.shを指定しています。

Dockerfile(14行目)
EXPOSE 3000

EXPOSE

EXPOSE | Docker ドキュメント日本語化プロジェクト >> Docs
コンテナの実行時にリッスンする、ネットワーク上のポートを指定します。今回は"3000"。

Dockerfile(17行目)
CMD ["rails", "server", "-b", "0.0.0.0"]

CMD

CMD | Docker ドキュメント日本語化プロジェクト >> Docs

CMD 命令の主目的は、コンテナの実行時のデフォルト処理を設定することです。

Dockerfileの命令で既にポートが3000に指定されているので、Railsのアプリケーションサーバーはポート3000で稼働します。

知りませんでしたが、"0.0.0.0"には、「特定のアドレスを指定しない」という意味があるようです。

下記リンクを参照しましたが、上記の解釈以上のことは難しくて分かりませんでした。それはまた後日。
127.0.0.1とlocalhostと0.0.0.0の違い - Qiita
What is the Difference Between 127.0.0.1 and 0.0.0.0? - How-To Geek

Dockerfileの内容についてはここで終わりです。
引き続きチュートリアルのその他の内容について、次回分にメモしていきます。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-06-29T06:42:12+09:00

WSL + Docker + VSCode でSQLサーバーをお手軽に立てよう

WSL + Docker + VSCode でSQLサーバーをお手軽に立てよう

だいぶ説明雑なのは知り合いの初心者向けに書いたからです

それぞれの概要

  1. WSL(WSL2)
- Microsoftが提供する仮想環境Hyper-Vがベースに使われた、Linux環境をWindows上で構築するシステム。
- ほぼ完全なLinuxが動作するため、従来Windowsが弱点としていたバックエンド開発(サーバー等の開発)にてLinuxのソフトウェア資源がそのまま利用できるようになった。

  1. Docker

    • コンテナ型仮想環境といわれる仕組みの仮想ソフトウェア。
    • 今までの仮想マシンに比べ、クラウドなどのスタートが同じ環境を複数人が異なるデータで使う場面や、開発中のテストに使い捨て環境を構築することがやりやすいのが利点

  2. VSCode

    • 最近はやりのEditorの一角
    • エディタだが拡張機能が多くIDE並みの環境を簡単に構築できる
    • Terminalを開きながらDockerの管理をしてSQLサーバにつなぐなんてこともできる

WSLのインストール

  1. 管理者でPowerShellをひらき(Windows + x　からPowershell(管理者))、以下のコマンドを一行ずつ入力する。

    
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

  2. 再起動し、再び管理者でPowershellを開く

    
curl "https://wslstorestorage.blob.core.windows.net/wslblob/wsl_update_x64.msi" -Outfile wsl_update_x64.msi -UseBasicParsing

start wsl_update_x64.msi

wsl --set-default-version 2

  3. MSStoreを開く

    わからなければWindows+Rでファイル名を指定して実行を開き、

    ms-windows-store:

    でもOK

  4. 検索ボタンを押し、Ubuntuと入力する

  • いくつかバージョンが出てくる(20.04など)が何もかいてないUbuntuを入手する

    • MSアカウントの設定がない場合、指示に従ってアカウントでログイン/サインアップする。
    • インストールが完了すると起動ボタンが出てくるのでクリック

  1. 初期設定

    1. Username:　という表示になったらユーザー名、EnterするとPassword: となるのでパスワードを入力する
    2. しばらく待つ
    3. セットアップが終わるとユーザー名 ~ $ の表記になり、入力可能になる
    4. sudo apt update && sudo apt upgrade -y と入力し、中のアプリケーションのアップデートをする。
    5. sudo apt -y install language-pack-japanese-ja　と入力し、日本語パックをインストールす
    6. sudo update-locale LANG=ja.JP.UTF8 と入力し、日本語を適用させる
    7. 一度ウインドウを閉じて、もう一度開くと日本語化が完了している。(スタートメニュー内のUbuntuから開ける)
    8. 完了

Dockerのインストール

  1. ダウンロードとインストール

    Powershellを開き

    curl "https://download.docker.com/win/stable/Docker%20Desktop%20Installer.exe" -outfile "Docker Desktop Installer.exe" -UseBasicParsing
start "Docker Desktop Installer.exe"

と入力し指示にしたがってインストールし、再起動する

  1. Docker Hub にサインアップ
  • https://hub.docker.com/ を開き、サインアップの画面になったらID,Mail,Passwordを入力
  • メールアドレスにメールが届くので開いてVerifyする
  • 完了したらタスクトレイ内のDockerを押すとsignin...というボタンがあるのでクリックしてID,Passwordを入力

  1. Dockerを開き、設定を開き(ギアマーク)、Use WSL ~にチェックが入ってるのを確認する

  2. 終わり

VScode

  1. https://code.visualstudio.com/を開いてダウンロード、インストール

  2. 起動して拡張機能ボタンを押して(or Ctrl + Shift + x)検索欄にJapaneseと入れると言語パックがでてくるのでインストール

  3. VSCodeを再起動する

  4. 拡張機能からDocker、mssqlをインストールする

  5. 終わり

DockerにMSSQLパッケージを入れてVSCodeから触る

  1. VSCodeでCtrl + @　でターミナルをだし、

    
docker login
docker pull  mcr.microsoft.com/mssql/server:2019-CU5-ubuntu-16.04

    と入力するとインストールされる

  2. そのままVSCodeのターミナルに

    
docker run  -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=PassW@rd" -p 1433:1433 --name sql1 -d mcr.microsoft.com/mssql/server:2019-CU5-ubuntu-16.04

    と入力するとSQLサーバーが立ち上がる

  3. VSCodeのMSSQLの接続でアドレスはlocalhost、IDはsa、Passwordは今回はPassW@rdと入力してログイン

  4. SQLサーバーにログイン完了

終了

  1. VSCodeの左側にDockerのアイコンが追加されているので、クリック

  2. containersにSQL1があるので右クリックしてstop

  3. もう一度右クリックしてremoveすればまっさらな環境から再スタートできる

  4. removeしなければ次に触りたいときにここからstartすると前回の状態から再開できる

よくある質問

Q. 仮想環境内にファイルいれたい

A. docker cp ローカルのパス　コンテナID:コンテナ内のパス でできるよ

Q.なんでこんなめんどくさいことするの？

A.新しい問題とかの時に前回のゴミが残るとそのほうが面倒くさいので

最後に

ファイアウォールとかに何か言われたら許可してください

インストールしてから書いているので違ったりするかもです
その時は教えてください

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-06-29T00:58:16+09:00

mongoose で docker でたてた MongoDB に接続するのにはまった話

はじめに

Python でせっせと実装していたものが、npm install すれば、あっという間に出来てしまうことを知り、少し落ち込んだりもしたけど、Node.js で書き直している私です。Node.js は超初心者です。

開発は1人でやっていて、まだ試しに作ってるだけの状態で、Mac にあれこれ DB をたてるのが嫌なので、DB だけ docker でやっちゃおう！とやってみたところ、ちっとも繋がりませんでした。

mongoose の Top ページ (ココ)に書いてある

const mongoose = require('mongoose');
mongoose.connect('mongodb://localhost:27017/test', {useNewUrlParser: true, useUnifiedTopology: true});

const Cat = mongoose.model('Cat', { name: String });

const kitty = new Cat({ name: 'Zildjian' });
kitty.save().then(() => console.log('meow'));

これのコピペが実行できないという絶望的な状況からのスタート。

動作環境

OS: MacOS Catalina Version 10.15.5 (19F101)
node: v12.18.1
mongoose: 5.9.20
MongoDB: 4.2.8
Docker: version 19.03.8, build afacb8b
docker-compose: version 1.25.5, build 8a1c60f6

docker-compose

docker-compose.yml
version: "3.1"

services:
  mongo:
    image: mongo
    restart: always
    environment:
      MONGO_INITDB_ROOT_USERNAME: user
      MONGO_INITDB_ROOT_PASSWORD: secret1234
    ports:
      - 27017:27017
    volumes:
      - ./configdb:/data/configdb
      - mongo_local_marketing:/data/db

  mongo-express:
    image: mongo-express
    restart: always
    ports:
      - 8081:8081
    environment:
      ME_CONFIG_MONGODB_ADMINUSERNAME: user
      ME_CONFIG_MONGODB_ADMINPASSWORD: secret1234

volumes:
  mongo_local_marketing:
    driver: local

ほぼ、公式(docker hub: mongo)のまま。永続化しただけ。express はなくても良いけど、MongoDB にも不慣れで便利なのでありがたく。

で、sandbox という名前の database を作っておく。

うまくいかなかったやり方

├── app.js
└── config
    └── db.js
config/db.js
module.exports = {
  url: "mongodb://user:secret1234@0.0.0.0:27017/sandbox",
};
app.js
const mongoose = require("mongoose");
const dbConfig = require("./config/db");

// connect mongodb
mongoose
  .connect(dbConfig.url, {
    useNewUrlParser: true,
    useUnifiedTopology: true,
  })
  .then(() => {
    console.log("successfully connected to the database");
  })
  .catch((err) => {
    console.log("error connecting to the database");
    console.log(err);
    process.exit();
  });

実行するとエラー

$ node app.js
error connecting to the database
MongooseServerSelectionError: Authentication failed.
    at NativeConnection.Connection.openUri (.../node_modules/mongoose/lib/connection.js:830:32)
    at Mongoose.connect (.../node_modules/mongoose/lib/index.js:335:15)
    at Object.<anonymous> (.../app.js:10:4)
    at Module._compile (internal/modules/cjs/loader.js:1138:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1158:10)
    at Module.load (internal/modules/cjs/loader.js:986:32)
    at Function.Module._load (internal/modules/cjs/loader.js:879:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
    at internal/main/run_main_module.js:17:47 {
  reason: TopologyDescription {
    type: 'Single',
    setName: null,
    maxSetVersion: null,
    maxElectionId: null,
    servers: Map { '0.0.0.0:27017' => [ServerDescription] },
    stale: false,
    compatible: true,
    compatibilityError: null,
    logicalSessionTimeoutMinutes: null,
    heartbeatFrequencyMS: 10000,
    localThresholdMS: 15,
    commonWireVersion: null
  }
}

reason... ナニコレ、さっぱり分からん。認証に失敗していることだけ分かった。これ、慣れたら reason 見て理由が分かるもの？！
user/password の typo か？と思ったけど、そうじゃない。user/password の渡し方がいかんのか？と思って以下のように変更。

config/db.js
module.exports = {
  url: "mongodb://0.0.0.0:27017/sandbox",
  user: "user",
  pwd: "secret1234",
};
app.js
const mongoose = require("mongoose");
const dbConfig = require("./config/db");

// connect mongodb
mongoose
  .connect(dbConfig.url, {
    useNewUrlParser: true,
    useUnifiedTopology: true,
    user: dbConfig.user,
    pass: dbConfig.pwd,
  })
...

ダメ。0.0.0.0 を localhost に変えてみたり、docker-compose に書いた monogo に変えてみたりしたけど、当然ダメ。

dbName を取ってみたら接続はできた

config/db.js
module.exports = {
  url: "mongodb://0.0.0.0:27017",
  user: "user",
  pwd: "secret1234",
};

こうすると、なんか接続はできた。しかし、MongoDB 上に Database は、

  • admin
  • config
  • local
  • sandobox

の4つが存在しており、どれにつながってるのか分からん状態。Database は増やせるし。
sandbox に最初からつながりたいんですよ、私は。たまたまつながってる状態じゃなくて、ちゃんと明示した通りにつながっていて欲しいんですよ、私は。

dbName をオプションで渡す

https://mongoosejs.com/docs/connections.html#options

ここを見ると、dbName もオプションで渡せるみたいなので、そのようにしてみた。

config/db.js
module.exports = {
  url: "mongodb://0.0.0.0:27017",
  user: "user",
  pwd: "secret1234",
  dbName: "sandbox",
};
app.js
const mongoose = require("mongoose");
const dbConfig = require("./config/db");

// connect mongodb
mongoose
  .connect(dbConfig.url, {
    useNewUrlParser: true,
    useUnifiedTopology: true,
    user: dbConfig.user,
    pass: dbConfig.pwd,
    dbName: dbConfig.dbName,
  })
  .then(() => {
    console.log("successfully connected to the database");
  })
  .catch((err) => {
    console.log("error connecting to the database");
    console.log(err);
    process.exit();
  });

const Cat = mongoose.model("Cat", { name: String });

const kitty = new Cat({ name: "Zildjian" });
kitty.save().then(() => console.log("meow"));

実行

$ node app.js
successfully connected to the database
meow

にゃー。
"sandbox" database の "cats" collection にジルジャン入ってました。シンバルか！

{
    _id: ObjectId('5ef8b261164eb0103f341ef6'),
    name: 'Zildjian',
    __v: 0
}

つながらなかった理由

わかりまｓｎ笑

同じ症状の人が見当たらなかったので、私の環境のせい？今度暇な時にゆっくり mongoose のソースコードを追ってみるかも知れない。

今日はいったん、ここまで。あと MongoDB に突っ込めばいったん開発おしまいなので、そっちをやってから。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-06-29T00:17:12+09:00

DockerでRadicale 3.0なうに使っていいよ。

Radicale 3.0リリース

Radicaleの新バージョンがリリースされていたので、公開しているDockerイメージを更新しました。
https://hub.docker.com/r/takeyamajp/radicale

Dockerfileはこちらです。
https://github.com/takeyamajp/docker-radicale/blob/master/centos8/Dockerfile

旧バージョンの記事はこちら。
https://qiita.com/takeyamajp/items/d7194853b0cbd3d5ef7a

概要

ほとんどの方は、カレンダーやリマインダー、そして連絡先などの個人情報をGoogleやApple、Microsoftなどに預けていると思います。
Radicaleは、それらの情報を保管する事ができるサーバーソフトウェアです。
https://radicale.org

自宅にDocker環境がある方は、すぐにでも個人情報を自分で管理し始めることが出来ます。

FROM centos:centos8

...

ENV TIMEZONE Asia/Tokyo

ENV SSL true

ENV LOG_LEVEL warning

ENV USER user1,user2
ENV PASSWORD password1,password2

VOLUME /radicale

EXPOSE 5232

管理画面には、下記のコマンドで起動してhttp://localhost:5232/にアクセスしてみて下さい。
スマホなどに登録するときはhttp://localhost:5232/user/みたいな感じて設定して下さい。（userの部分はユーザー名です）

docker run -d --name radicale \
       -e TIMEZONE=Asia/Tokyo \
       -e SSL=false \
       -e USER=user \
       -e PASSWORD=password \
       -p 5232:5232 \
       takeyamajp/radicale;

DockerHubやGitHubでスター頂けると励みになります。
それでは、良いRadicaleライフを。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧