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

コンテナからプロセスID(pid)を確認する

docker inspect [container ID]で確認できる。

検証

  1. コンテナを二つ立ち上げる
$ docker run --name alpine_test -itd alpine
148c39d151fab8861c2527a15b13d1a613f9bfa02b0a8b1284b64e82f9f2dff2
$ docker run --name alpine_test_2 -itd alpine
e7f8a6a77b2a03928b68e3256c75f01a45b058ffadeaa243aef9a70dc12a1381
$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
148c39d151fa        alpine              "/bin/sh"           3 seconds ago       Up 1 second                             alpine_test
40e81cafeafd        alpine              "/bin/sh"           About an hour ago   Up About an hour                        alpine_test_2
  1. 立ち上げたコンテナのプロセスIDを確認する
ps aux | grep "/bin/sh"
PID   USER     TIME  COMMAND
  216 root      0:00 /bin/sh
  406 root      0:00 /bin/sh
  526 root      0:00 grep bin/sh

216, 406のプロセスがどのコンテナに割り当たっているのか、プロセスIDだけ見ても分からない。

  1. コンテナの情報を取得する
$ docker inspect alpine_test | grep Pid
            "Pid": 406,
            "PidMode": "",
            "PidsLimit": 0,

Pidが、プロセスID。

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

biocontainers の特定のバージョンの trim_galore --fastqc で処理が止まる問題

概要

--fastqc オプションがないと、正しくおわる
--fastqc オプションをとめると、処理が止まる。落ちるわけではない

結論

以下の解決策のとり方がある。

BioContainers の検索はこちらからできます。

  • biocontainers であれば、新しいバージョンがあるかを調べる。
  • 同じバージョンでも、最後の番号が新しいとなおっているかもしれない
  • なければ、自分でつくるか、他の人が作ったコンテナを探すという手がある。

なにか変更したら、期待通りに動くことを確認すること。
少ししかバージョンが変わっていなくても、出力がかわることがあるため。

参考

似たような問題で、biocontainersの特定バージョンの、picardで似たようなことがあった。
これも、少し新しいバージョンのものを使うことで解決した。

他のバージョンに解決済みだが、バージョンによっては、期待通りに動かないことがあったもの。

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

ローカルのプログラムやコマンドを k8s クラスタ内で実行する方法

はじめに

  • 以下の様なモチベーションから、同僚に聞いた方法をまとめました
    • k8s クラスタ上の Pod に対して、自作のプログラムでリクエストを投げたい
    • kubectl port-forward でもできるけど、いろんな Pod に投げたいので、何個も port-forward するのはだるい

想定

  • GKE 上のクラスタで一時的にプログラムを動かしたい(クラスタ上のイメージには使えるものがない)
  • GCR HostName: asia.gcr.io
  • GCP ProjectName: gcp-project-hoge

Docker イメージを作る

  • Dockerfile
# 動かしたいプログラムのバイナリと以下のDockerfile を同じ場所に置く
FROM ubuntu:latest

COPY ./app .
  • build docker image
# sample-image-name は適当
$ docker build . -t asia.gcr.io/gcp-project-hoge/sample-image-name

GCR に push する

$ docker push asia.gcr.io/gcp-project-hoge/sample-image-name:latest

k8s クラスタにデプロイ

# sample-pod は適当な pod 名
# デプロイしたい k8s の context に切り替えておくこと 
# 実行後、Docker コンテナにログインした状態になり(-it)、 exit すると Pod は削除される(--rm)
$ kubectl run sample-pod --restart=Never -it --rm --image asia.gcr.io/gcp-project-hoge/sample-image-name:latest
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

超初心者がMacでDocker/Laradock環境構築 備忘録

作りたいアプリが決まったら、まずは何はともあれ環境構築。
これをやらなきゃ始まらない。

私はプログラミング学習を始めたばかりのころWindowsを使用していたため
これまではcloud9にて学習していたのですが。

cloud9は予期せぬ動きをすることがあるので
便利だけどあまりおすすめはしないと現役プログラマーさんにアドバイスをされ、
(ここら辺は完全に個人の好みだとは思いますが…実際私も使っていてハァ?!ってなった事はある)

PCも学習途中で最新Macに買い替えたことだし、せっかくならばIDEじゃなくて
仮想サーバー構築してwebアプリ処女作品を作っていこうかなと、そう思ったわけです。

まずはDockerのインストール

数あるものの中からなぜDockerを選んだのかというと、
単におすすめされた内のひとつだったのと、注目度が高いって聞いたから。
Laradockなんて便利なものもあるしね。

まあ、詳しい説明は割愛。

【ここ】からダウンロードに進む。

メールアドレス、ID、PWを設定したらリンク先からDockerをダウンロードする。

そしてDockerAppを起動し先ほど登録したIDとPWを入力してログインしておく。
たったこれだけ。なんて簡単。

もしくはターミナルで

$ brew install docker
$ brew cask install docker

を実行するだけ。

(私はたぶん途中で失敗してて
ダウンロードしてターミナルでコマンド実行、どっちもやらないと上手くいかなかった。)

次はLaradockのインストール

これはLaravel+Dockerを手軽に構築できるすごいやつ。ありがたい。

インストール&初期設定方法はLaradock公式にも載っているのだけれど、
英語に普段馴染みのない私にはちょっと分かりにくかったので、Qiitaの投稿を参考にしました。
(参考にさせていただいた記事はページ下部にまとめて記載)

なんの準備もしていなかった私は、まずは勉強用フォルダを作成。
で、その中に今回作るアプリのフォルダを作成。

$ mkdir study && cd study
$ mkdir first_app

仮名だけどこんな感じ。

そしたら次はfirst_appフォルダ内に、Laradockをクローンする。
(gitは事前に設定済み)

$ git clone https://github.com/Laradock/laradock.git

クローンするのはちょっと時間がかかった気がする。

これが終わった時点でstudyフォルダ内には、クローンによって作られたlaradock
先ほど作ったfirst_appの2つのフォルダが入っているはず。

ここまでできたらlaradockフォルダに移動して、env-exampleをコピーして.envの作成。

$ cd laradock
$ cp env-example .env

.envファイル一部編集。
(隠しファイルを表示する設定をしていなくて、コピーした.envがない!って焦ったのはひみつ)

APP_CODE_PATH_HOST=../
// ここを変更 ↓
APP_CODE_PATH_HOST=../first_app

ここまでできたら、一度コンテナを作成して実行する。

$ docker-compose up -d nginx mysql redis

実行したいものが他にあればこの後ろに追記していく。
正直ここら辺はよくわかってないけど、ひとまずはこれでいいかな。

初回の実行にはかなり時間がかかるので、目の休憩も兼ねてまったり休憩タイム。

インストールが終わったら、http://localhost にアクセスしてみて404エラーのページに繋がったらOK!
うまくいってます!天才!

続いてLaravelのインストール

インストール祭りですね。ここらへんから私は疲れてきた。

laradockフォルダ内のworkspaceフォルダに移動。
そしてその中に、Laravelをインストールしていきます。

workspaceへはログインが必要なのですが
そのままroot権限ユーザーでLaravelをインストールしようとすると「Worning!」って注意されてインストールできない。

なのでここではlaradockユーザーでログインする。

$ docker-compose exec --user=laradock workspace /bin/bash
$ composer create-project --prefer-dist laravel/laravel first_app

ここも長い時間がかかるので、リラックスしながら待ちます。
無事にインストールが完了したら、セットアップはあと少し!

今度はfirst_app内の.envファイルの編集です。

/* 変更前
DB_HOST=127.0.0.1
DB_DATABASE=homestead
DB_USERNAME=homestead */

DB_HOST=mysql 
DB_DATABASE=default 
DB_USERNAME=default 

それが終わったら、workspaceからログアウトして、dockerに再起動をかけます。

laradock@~~~~~~~:/var/www$ exit
$ docker-compose stop
$ docker-compose up -d nginx mysql redis

再度http://localhost にアクセスしてみて、今度はLaravelのTOPページが表示されていれば成功です!
難しくはないけど、初心者には長い道のりでした...。

本当はMySQLの細かい設定も一気に行ったほうが後々楽なのでしょうが、ここで一区切りにしました。
だって疲れたんだもの。

走らせたコンテナは、きちんとstopさせます。

$ docker-compose stop

ここまでをfirst commitしてgithubにpushで本日の作業は終了。ふ〜〜。

お疲れ様でした。

参考記事

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

Dockerで、さくっとGrafanaを起動するスクリプト

以下の内容を、start-grafana.shファイルで保存して実行。

IMAGE_NAME=grafana/grafana
CONTAINER_NAME=grafana

for container_id in $( docker container ls --all --quiet --filter name=$CONTAINER_NAME); do
  docker container rm --force ${container_id}
done

docker container run \
  --detach \
  --env "GF_SERVER_ROOT_URL=http://localhost:3000" \
  --env "GF_INSTALL_PLUGINS=grafana-polystat-panel,bessler-pictureit-panel" \
  --mount type=volume,source=grafana_lib,target=/var/lib/grafana \
  --name=$CONTAINER_NAME \
  --publish 3000:3000 \
  $IMAGE_NAME 

echo "http://localhost:3000 login to grafana with admin/admin"

プラグインを追加したい場合は、下記の部分にプラグイン名を追加して、再実行。

  --env "GF_INSTALL_PLUGINS=grafana-polystat-panel,bessler-pictureit-panel" \
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

pipenvによるpythonアプリケーション実行環境をDockerとVirtualBox(Vagrant)で作る

前置き

pythonでバッチやWebアプリケーション(Django/Flask等)の環境を作るときのベースイメージとなるものをDockerとVagrantで作ったのでその記録です。(DockerもVagrant(VirtualBox)もベースはCentOS(7.6)です)

本当は、nginxやuWSGIなどとの連携や簡単なアプリケーションまで作って載せよう思いましたが、長くなったので、気が向いたら書くことにします。

Dockerコンテナ版

前提

sshで接続できるpipenvで作るpython実行環境のDockerコンテナのサンプルです。
これをこのまま利用するというよりはこれでビルドしたイメージをベースにDjangoやuWSGIをインストールした派生イメージを作ったり、pythonのバッチアプリケーションを実行するコンテナを作ったりする想定で作ったものです。

試したDockerのバージョンは以下の通りです。

Client: Docker Engine - Community
 Version:           18.09.2
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        6247962
 Built:             Sun Feb 10 04:12:39 2019
 OS/Arch:           darwin/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.2
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.6
  Git commit:       6247962
  Built:            Sun Feb 10 04:13:06 2019
  OS/Arch:          linux/amd64
  Experimental:     false

Dockerfileの中身

FROM centos:7

ARG APP_USR_PWD
ARG BASE_GROUP=apps
ARG APP_USER=app
ARG APP_HOME=/home/app
# only python3.x.y
ARG PYTHON_VERSION=3.7.4

RUN test -n "${APP_USR_PWD}" && \
    groupadd ${BASE_GROUP} && \
    useradd -d ${APP_HOME} -G ${BASE_GROUP} -s /bin/bash ${APP_USER} && \
    yum install -y epel-release && \
    yum install -y https://centos7.iuscommunity.org/ius-release.rpm && \
    yum install -y sudo python-pip openssh openssh-server passwd logrotate sudo wget vim jq \
    gcc git libffi-devel zlib-devel bzip2 bzip2-devel readline readline-devel sqlite sqlite-devel openssl openssl-devel && \
    yum -y update && yum -y clean all && rm -rf /var/cache/yum/ && \
    echo "${APP_USER}:${APP_USR_PWD}" | chpasswd && \
    echo "${APP_USER} ALL=(ALL) ALL" > /etc/sudoers.d/${APP_USER} && \
    pip install pip --upgrade && pip install pipenv

# install pyenv
RUN git clone https://github.com/pyenv/pyenv.git ${APP_HOME}/.pyenv && \
    chown -R ${APP_USER}:${BASE_GROUP} ${APP_HOME}/ && \
    echo '' >> ${APP_HOME}/.bash_profile && \
    echo 'export PYENV_ROOT="${HOME}/.pyenv"' >> ${APP_HOME}/.bash_profile && \
    echo 'export PATH="${PYENV_ROOT}/bin:${PATH}"' >> ${APP_HOME}/.bash_profile && \
    echo 'if command -v pyenv 1>/dev/null 2>&1; then' >> ${APP_HOME}/.bash_profile && \
    echo '  eval "$(pyenv init -)"' >> ${APP_HOME}/.bash_profile && \
    echo 'fi' >> ${APP_HOME}/.bash_profile && \
    echo "export PIPENV_DEFAULT_PYTHON_VERSION=${PYTHON_VERSION}" >> ${APP_HOME}/.bash_profile && \
    echo 'export PIPENV_VENV_IN_PROJECT=true' >> ${APP_HOME}/.bash_profile

# install python.
RUN su - ${APP_USER} -c "pyenv install ${PYTHON_VERSION} && pyenv global ${PYTHON_VERSION} && pyenv rehash && pip install --upgrade pip && pip install pipenv"

# setup ssh.
RUN ssh-keygen -q -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa && \
    ssh-keygen -q -f /etc/ssh/ssh_host_ecdsa_key -N '' -t ecdsa && \
    ssh-keygen -q -f /etc/ssh/ssh_host_ed25519_key -N '' -t ed25519 && \
    mkdir -p ${APP_HOME}/.ssh && chmod 700 ${APP_HOME}/.ssh
# Add public key to container.
ADD id_rsa.pub ${APP_HOME}/.ssh/authorized_keys
RUN chown -R ${APP_USER}:${BASE_GROUP} ${APP_HOME}/.ssh/

EXPOSE 22

ENTRYPOINT ["/usr/sbin/sshd", "-D"]

事前作業

  • Dockerfileと同じディレクトリにSSHログインする秘密鍵に対応する公開鍵をid_rsa.pubというファイル名で配置すること!!
  • 社内のプロキシ環境下の場合は、DockerfileのFROMの直後当たりに環境変数の設定を追加する。

例)

FROM centos:7

ENV http_proxy=http://proxy.xx.yy:9999 \
    https_proxy=http://proxy.xx.yy:9999

# 以下省略・・・

ビルド方法

docker build -t {イメージ名}[:{タグ}] --build-arg APP_USR_PWD={SSHログインユーザがsudoするときに必要なパスワード}

上記以外に以下の値が--build-argで上書き可能である。

  • BASE_GROUP:アプリケーションの実行(=SSH接続)ユーザの所属グループ(デフォルトapps
  • APP_USER:アプリケーションの実行(=SSH接続)ユーザ名(デフォルトapp
  • APP_HOME:アプリケーションの実行(=SSH接続)ユーザのホームディレクトリ(デフォルト/home/app
  • PYTHON_VERSION:pipenvでインストールするアプリケーションの実行(=SSH接続)ユーザのグローバルのpythonバージョン(デフォルト3.7.4)

PYTHON_VERSIONはすべてのバージョンを確認しているわけではないので、指定するものによってはインストールするパッケージが不足している可能性もあります。

起動方法

docker run -d -p ホスト側のポート番号:22 --name {任意のコンテナ名} {イメージ名}[:{タグ}]

dockerホストからのアクセス

  • root
    docker exec -it {任意のコンテナ名} bash
  • app
    docker exec -it --user app {任意のコンテナ名}

Dockerホスト外からSSH接続方法

DockerホストOS側のファイアーウォール設定などで起動方法に記載した「ホスト側のポート番号」でアクセス可能であること。
(この点についてはDockerホスト環境に依存するので割愛)

接続情報は以下の通りです。適宜、利用するSSHクライアントツールに以下の情報を指定してください。

  • ホスト:接続元から見たDockerホストのホスト名 or IPアドレス
  • ポート番号:起動方法に記載した「ホスト側のポート番号」
  • ユーザ:app(--build-arg APP_USER=xxxとした場合はxxx)
  • 秘密鍵:Dockerfileと同じディレクトリに配置した公開鍵の秘密鍵

Vagrant+VirtualBox版

前提

VagrantのproviderはVirtualBoxを前提としていますが、VagrantfileのVirtualBox依存部分を他のプロバイダーに書き換えれば、問題なく動くと思います。
Vagrant版を作ったのはDockerが動かない(正確には動かすのにいろいろな作業が必要になりそう)環境の人がいたので、急遽つくったのものなので、
DockerfileのRUNでいろいろインストールしているところを外だしのprovistion.shに移したものです。
個人的には、実稼働環境の構築も考慮して、Ansible-Playbookで書きたいところなので、そのうち気が向いたら書き直します。

試したVagrantとVirutualBOXのバージョンは以下の通りです。

$ VBoxManage --version
6.0.8r130520
$ vagrant version
Installed Version: 2.2.5
Latest Version: 2.2.5

You're running an up-to-date version of Vagrant!

事前作業

  • Vagarnt sshでログインできるのでSSHの設定は特別には行っていません。
  • 社内のプロキシ環境下の場合は、以下の作業を実施しておくこと。
    • vagrant-proxyconfをインストールする。
      vagrant plugin install vagrant-proxyconf
    • 環境変数にhttp_proxy/https_proxy/no_proxyを登録する。)

Vagrantfileとprovision.sh

Vagrantfileのprovision設定をinlineで書くとみづらい&書きづらいのでprovision.shに外だししました。

forwarded_portのホスト側のポート番号、private_networkのIPアドレス、sync_folderのパス部分は各自の環境に合わせて変更してください。

Vagranfile
# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|

  # 利用するプラグイン定義
  config.vagrant.plugins = ["vagrant-vbguest", "vagrant-winnfsd"]

  # boxイメージ指定
  config.vm.box = "centos/7"
  config.vm.box_version = "1902.01"
  config.vm.box_check_update = false

  # GuestAdditionsを更新しない
  config.vbguest.auto_update = false

  # プロキシ設定
  if Vagrant.has_plugin?("vagrant-proxyconf")
    if ENV['http_proxy']
      config.proxy.http = ENV['http_proxy']
    end
    if ENV['https_proxy']
      config.proxy.https = ENV['https_proxy']
    end
    if ENV['no_proxy']
      config.proxy.no_proxy = ENV['no_proxy']
    end
  end

  # ポートフォワード設定(外部PCからのSSHアクセス用)
  config.vm.network "forwarded_port", id: "ssh", guest: 22, host: 2222

  # NFSに必要なprivate(host only)ネットワーク
  # ipの代わりに`type: "dhcp"`でも可。
  config.vm.network :private_network, id: "default-network", ip: "192.168.132.101"

  # ホスト名
  config.vm.hostname = "app.python.localohost"

  # ローカルでコーディングしたものをNFSマウントでゲスト側に認識させるためのディレクトリ
  # ⇒アプリを置く場所の想定です。
  config.vm.synced_folder ".", "/home/vagrant/apps", type: "nfs", nfs_export: true, nfs_version: 3

  # ゲストOSのリソースは適宜変更してください。
  config.vm.provider :virtualbox do |vb|
    vb.name = "python-app" # VirtualBox上のゲストOS名
    vb.gui = false
    vb.memory = 2048
    vb.cpus = 2
    vb.check_guest_additions = false
    vb.functional_vboxsf     = false
  end
  # python3に必要なパッケージやpipenv(pyenv)のインストールなど。
  config.vm.provision :shell do |shell|
    shell.name = 'provision'
    shell.env = {
      :PYTHON_VERSION => "3.7.4",
    }
    shell.path = "provision.sh"
  end
end
provision.sh
#!/bin/bash
set -eo pipefail

echo "Start provision!!"

# パラメータ定義
# pythonのバージョン定義(環境変数で上書き可能)
PYTHON_VERSION=${PYTHON_VERSION:-"3.7.4"}
# めんどくさいのでvagrantをそのまま使う。
APP_GROUP="vagrant"
APP_USER="vagrant"
APP_HOME="/home/${APP_USER}"

# rootのssh接続を不可/パスなし接続不可(公開鍵認証のみ)
sed -i -e 's/#PermitRootLogin yes/PermitRootLogin no/' \
       -e 's/#PermitEmptyPasswords no/PermitEmptyPasswords no/' /etc/ssh/sshd_config

# パッケージのインストール等
# epelとiusの追加
yum install -y epel-release https://centos7.iuscommunity.org/ius-release.rpm
# update
yum update -y
# 必要なパッケージの追加(pythonに特化すれば全部ではなく、一部はサーバー上に必要そうなコマンド群も含む)
yum install -y wget jq git openssl \
               gcc python-pip python-devel \
               zlib-devel libffi-devel bzip2-devel \
               openssl-devel ncurses-devel sqlite-devel \
               readline-devel tk-devel gdbm-devel \
               libuuid-devel xz-devel systemd-devel
# お掃除
yum -y clean all && rm -rf /var/cache/yum/

# pyenvをインストールする
git clone https://github.com/pyenv/pyenv.git ${APP_HOME}/.pyenv
# アプリユーザで利用できるようにインストール
cat << EOS >> ${APP_HOME}/.bash_profile
# Add pyenv setting
export PYENV_ROOT="\$HOME/.pyenv"
export PATH="\$PYENV_ROOT/bin:\$PATH"
if command -v pyenv 1>/dev/null 2>&1; then
    eval "\$(pyenv init -)"
fi
export PIPENV_DEFAULT_PYTHON_VERSION=${PYTHON_VERSION}
export PIPENV_VENV_IN_PROJECT=true
EOS
chown -R ${APP_USER}:${APP_GROUP} ${APP_HOME}/.pyenv
# アプリケーションユーザ用のpythonはpyenvでglobalにセット
su - ${APP_USER} -c "pyenv install ${PYTHON_VERSION} && pyenv global ${PYTHON_VERSION} && pyenv rehash && pip install --upgrade pip && pip install pipenv"

echo "Fisnish provision!!"

起動方法

Vagrantfile/provision.shを同じディレクトリにおいて、そのディレクトリをカレントにした状態で

vagrant up

ホストからのアクセス

vagrant ssh

VirtualBoxホスト外からSSH接続方法

ホストOS側のファイアーウォール設定などで起動方法に記載した「ホスト側のポート番号」でアクセス可能であること。

接続情報は以下の通りです。適宜、利用するSSHクライアントツールに以下の情報を指定してください。

  • ホスト:接続元から見たVirtualBoxホストのホスト名 or IPアドレス
  • ポート番号:2222
  • ユーザ:vagrant
  • 秘密鍵:vagrant ssh-configで実行した``に秘密鍵のパスが記載されています。

例)

Host default
  HostName 127.0.0.1
  User vagrant
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile {カレントディレクトリ}/.vagrant/machines/default/virtualbox/private_key
  IdentitiesOnly yes
  LogLevel FATAL

なお、これはUnix/Linux/Macなどの${HOME}/.ssh/configに記載する内容となります。ただ、上の設定はlocalhostを前提にしているのでHostNameに指定する値は接続元から見たVirtualBOXホストのホスト名 or IPアドレスにしてください。
また、先頭のdefaultはVagrantの識別名なのでここも任意変更可能で、例えばHost pythonのように指定した場合、ssh pythonのように打つことでログインすることができます。(Vagrantの仕様とは直接関係ないので細かいことは割愛)

SSH接続後の利用例(共通)

pipenvのことが書きたいわけではないので、ほんの触りだけ。。。

# プロジェクトディレクトリ作る。
mkdir test
cd test
# pipenv(pyenv)による仮想環境を作る
pipenv --python 3.7.4
# =>これでPipfileが作られる
# PyPIパッケージモジュールをインストールする(上位人気のPyPIパッケージ)
pipenv install simplejson setuptools requests python-dateutil PyYAML
# => Pipfileに追記され、Piplockファイルにインストールされたバージョン情報とか諸々書き込まれる
# あとは作るものに依存するので割愛します。

追記

↑のVagrantfileのconfig.vm.synced_folder ".", "/home/vagrant/apps", type: "nfs"の部分についてですが、VPN接続時にマウントエラーが発生するという事象にぶち当たりました。
回避方法は別記事にしましたので、ご参照ください。

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

CSSの変更が反映されない

現象

HTMLとCSSを勉強のため、dockerとnginxでwebサーバーを構築したが、CSSを変更しても反映されなかった。

対処法

調べたところ、nginx.confのsendfileをoffにすればよいとわかった。

nginx.confの確認
$ docker exec -it コンテナID /bin/bash
$ cat /etc/nginx/nginx.conf

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

nginx.confの編集

docker内のファイルを直接編集する方法がわからず、以下のコマンドでローカルにコピー。

$ docker cp nginx_web_1:/etc/nginx/nginx.conf .

nginx.confのsendfileをoffに変更。

nginx.conf
sendfile        off;

docker-compose.ymlに以下を追加し、confファイルをコンテナにマウント。

docker-compose.yml
'- ./nginx.conf:/etc/nginx/nginx.conf'

コンテナを再度作成

$ docker-compose up

直らず

CSSを削除しても変わらなかったので、ブラウザが原因だと思い、
デベロッパーツールからブラウザのキャッシュをクリアしたところ直った。
CSSが反映されないときはとりあえずブラウザのキャッシュを疑うべきとのことらしい。
スクリーンショット 2019-07-11 1.31.47.png

参考

https://qiita.com/shoyan/items/12389d5beaa8695b1a53
https://qiita.com/gologo13/items/7e4e404af80377b48fd5

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

chromiumをdocker上でビルド・実行する

概略

chromiumのソースコードをクローンしてコンパイルして実行する。

環境

ubuntu 19.04

ただし、chromiumの推奨開発環境は

Most development is done on Ubuntu (currently 16.04, Xenial Xerus).

との事なので、dockerで擬似的に16.04の環境を作ることにする。

install docker

dockerとは?→
https://knowledge.sakura.ad.jp/13265/

docker.io を apt-get して docker をインストール。

sudo apt install docker

公式のubuntuのイメージファイルが存在するので、環境構築は困らない。
https://hub.docker.com/_/ubuntu

16.04のタグがついたdockerイメージをpull docker pull ubuntu:16.04 して取得。

あとは、docker run -it imagefilename するだけで起動する。

が、今回はGUIアプリを実行しようとしているので、ホストPCのXサーバの情報を渡して起動する必要がある。
その起動コマンドは、以下のようになる。
ソケットの共有と環境変数のコピーを行っているよう。

$ sudo docker run -it -e DISPLAY=$DISPLAY -v /tmp/.X11-unix/:/tmp/.X11-unix ubuntu:16.04

また、コンテナからホストへXサーバの接続を許可するために、ホスト側で次のコマンドを打つ。

$ xhost local:

この辺りの話は下記URLに詳しく書かれています。

https://unskilled.site/docker%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E3%81%AE%E4%B8%AD%E3%81%A7gui%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E8%B5%B7%E5%8B%95%E3%81%95%E3%81%9B%E3%82%8B/

build chromium

次の手順を進めるだけ。

https://chromium.googlesource.com/chromium/src/+/master/docs/linux_build_instructions.md

とりあえず apt update しておく。

# apt update
Get:1 http://security.ubuntu.com/ubuntu xenial-security InRelease [109 kB]
Get:2 http://archive.ubuntu.com/ubuntu xenial InRelease [247 kB]
Get:3 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages [892 kB]
...

gitをインストール

# apt install git
...
# git --version
git version 2.7.4

作業用ディレクトリを作り、ツールを git clone する

/ # cd ~
~ # mkdir work
~ # cd work
~/work # git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git

パスを通しておく

# PATH=$PATH:`pwd`"/depot_tools"
# echo export PATH=$PATH:`pwd`"/depot_tools" >> ~/.bashrc 

chromium を拾ってくる・・・pythonが無い

~/work# mkdir chromium
~/work# cd chromium/
~/work/chromium# fetch --nohooks chromium
/root/work/depot_tools/fetch: line 8: exec: python: not found
apt install python

もう一度実行するが・・・ curl が無い

...
Your platform is missing a supported fetch command. Please use your package manager to install one before continuing:

  curl
  wget
...
apt install curl

途中で止めてしまったので、いろいろ汚くなってしまった。一旦消す。

~/work/chromium# fetch --nohooks chromium
Running: gclient root
Your current directory appears to already contain, or be part of, 
a checkout. "fetch" is used only to get new checkouts. Use 
"gclient sync" to update existing checkouts.

Fetch also does not yet deal with partial checkouts, so if fetch
failed, delete the checkout and start over (crbug.com/230691).

~/work/chromium# ls
_gclient_src_kXTDYS

~/work/chromium# rm * -rf

~/work/chromium# fetch --nohooks chromium
Running: gclient root
Your current directory appears to already contain, or be part of, 
a checkout. "fetch" is used only to get new checkouts. Use 
"gclient sync" to update existing checkouts.

Fetch also does not yet deal with partial checkouts, so if fetch
failed, delete the checkout and start over (crbug.com/230691).

~/work/chromium# ls -a
.  ..  .gclient

~/work/chromium# rm .gclient 

~/work/chromium# fetch --nohooks chromium

lsb-release が無い

# cd src
# ./build/install-build-deps.sh
ERROR: lsb_release not found in $PATH

apt install lsb-release

sudo が無い

# ./build/install-build-deps.sh
./build/install-build-deps.sh: line 132: sudo: command not found

apt install sudo

以下、まったりタイムです

# ./build/install-build-deps.sh
# gclient runhooks
# gn gen out/Default
# autoninja -C out/Default chrome

execute chromium

chromiumの実行です。

out/Default/chrome
Running as root without --no-sandbox is not supported. See https://crbug.com/638180.

rootで起動しようとすると、--no-sandbox オプションが必須になる。
アカウントを新規作成しても良いですが、面倒なので。

out/Default/chrome --no-sandbox

これでブラウザが表示されるはず。

もし

Gtk: cannot open display: 

が出たら、Docker起動時のオプション辺りを見直してください。

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