- 投稿日：2020-06-24T23:36:38+09:00
[Windows][Docker] nodeコンテナでnpm installが動かず地獄を見た
どおおおおもおおおお
受諾案件で掲題のことをして地獄を見ましたyagrushです引き継いだのは、nodeにgulpやらbabelやらonsen-uiやら大量にインポートしたサーバーアプリケーション。
これ、いままでvagrantで動いてたらしいんだけど、docker化せねばならない。
しかもマルチOS（Windows, Mac, Linux）で。現状
- ルートディレクトリに package.json は残っていました。
- /node_modules はありませんでした。
（そもそも、違う環境の /node_modules は（環境依存モジュールが有る可能性があるので）流用する気はないですけれども）package.json をたよりに npm install してみんとす
- Mac ... 奇跡的に動いた。
Linux ... 奇跡的に動いた。
Windows ...
npm ERR! code ENOENT npm ERR! syscall open npm ERR! path /xxxxxxxxxxx/xxxxxxxxxxx/xxxxxxxxxxx npm ERR! errno -2 npm ERR! enoent ENOENT: no such file or directory, open '/xxxxxxxxxxx/xxxxxxxxxxx/xxxxxxxxxxx' ...npm ERR! Maximum call stack size exceeded"Failed to load external module @babel/register"これらのエラーが途中で無秩序に発生します・・・
上記３種のエラーが出て止まればまだマシな方で、最悪、Docker Desktopがハングアップします…なおコマンドインターフェース上のプログレス表示の傾向としては、
- 最初は快速にnpm installが進行していきますが、
- だんだん遅くなり、
- やがて永眠します…
（なんだか、メモリリークを大リファクタリングした昔の仕事を彷彿とさせるなぁ…）
トライアンド全部エラー
ネット上には、同様に犠牲となった多数の猛者たちの夢の跡が散見されるのですが、
- npm install --no-bin-links ← すでにやっとるがな！
- rm -f package-lock.json ← すでにやっとるがな！！
- docker desktopの性能設定を上げる
- npm cache clean --force
- .npmignore を作る
- npm rebuild
- npm config set registry http://registry.npmjs.org/
- package.jsonをすべて手書きのnpm installにする
ええ、全部やってみましたとも
対処方法
よかろう！！
貴様がその気なら、こちらにも考えがあるわ！！！というわけで、超スーパー泥臭対応で解決しました。
- docker-nodeコンテナのワークディレクトリをdocker-compose.ymlなどでvolumeマウントしておく。
- 何度もnpm installする。
- コケてもハングアップしても /node_modules は絶対削除せずに、何度もリトライ。
- npm installコマンドは、/node_modules にすでにあるものを飛ばして次のモジュールをインストールする。
- やがて、/node_modules が完成された姿として満たされていく・・・！
- そしてあなたは、ついに暁の空を目撃するであろう。（npm installを完遂したことになり次の処理に移れる）
- 血と汗とともに完成した /node_modules を（volumeマウント経由でdockerコンテナから確保し、）/windows_node_modules などとして大事に大事に「よしよしいい子だ～」と言って秘蔵しておく。
- ビルドスクリプトを修正し、次回からは npm install を実行させるのではなく、/windows_node_modules を
mv windows_node_modules node_modulesで済ませるようにする。あとがき
はーマジ鬼門だわ
現象から想像するに、Windows * (npm on Docker) 固有の問題なのかねぇ…。
今度余裕あればnpmじゃなくてyarnで試してみようかな
（意外と動いたりしそうで怖い）
- 投稿日：2020-06-24T19:56:27+09:00
Kubernetes環境のバックアップ最適解！（実践編）
はじめに
構築編に続く実践編です。
記事の末尾にリンクしている弊社イベントでの動画も是非ご覧ください！何をバックアップすれば良いのか？
永続データの保護
構築編でも冒頭で触れましたが、コンテナの世界でもエンタープライズアプリケーションを動かしたいという需要が高まるにつれて、コンテナも永続データを持ち始めました。永続的なデータは企業にとって損出した場合の影響も大きく、確実に保護しておかなければいけない部分です。
コンテナ環境のバックアップ
コンテナ環境で永続データだけ保護だけでは不十分だと考えております。
コンテナ・k8s環境の構築はそんなに簡単ではありません。構築し慣れている人にとっては問題ないのかもしれませんが、苦労して構築した環境が壊れてしまい、再度チャレンジするにはなかなかの精神力が必要です。
さらに、実際に運用が始まり、様々なPodが稼働、多くのエンジニアが使う基盤になった場合に環境自体が壊れてしまったら…とコンテナ環境の管理者側の立場で考えると背筋が凍ります。
そんなリスクを最小化し、万が一の際にも簡単に復元できるようにコンテナ環境自体の保護も考える必要があります。永続データのバックアップ
実はクライアントコンテナのデプロイが完了していれば、あとはNetBackupから任意のデータをバックアップするだけなので非常に簡単です。
NetBackupの管理コンソールから、
・Standardポリシーを指定
・アクセラレータ（永久増分バックアップ機能）も利用可能
・バックアップスケジュールの設定
・クライアントコンテナのホスト名を認識
・バックアップ対象領域を指定
以上を設定したバックアップポリシーを作成して実行するだけです。コンテナ環境でも今までと変わりのないオペレーションで永続データの保護ができます。
コンテナ環境のバックアップ
保護すべき部分は？
今回はk8s環境の保護を例にHPE様と共同検証を行いました。
k8sには「/etcd」という領域があり、k8sクラスタの心臓部分です。
通常、マスタノード自体はクラスタ化されているため、バックアップが必要なの？という思われる方もいらっしゃるかもしれませんが、クラスタはシステムの可用性を高めて稼働率を担保するソリューションではありますが、バックアップにはなり得ません。例えば、オペレーションミスで間違った更新をかけてしまい、それを他のノードが同期してしまえば環境は壊れます。バグに当たることやランサムウェアなどのサイバー攻撃に合う可能性もあります。これらから保護できるソリューションはバックアップだけですので、「/etcd」を保護しておくと安心です。etcdのバックアップ検証環境
検証環境は以下の通りです。
etcdのバックアップの流れ
① /etcdのスナップショットを定期的に取得するJobPodを作成
② コンテナストレージにバックアップファイルを保存job_sample.yamlapiVersion: batch/v1beta1 kind: CronJob metadata: name: etcd-snapshot namespace: veritas spec: concurrencyPolicy: Forbid schedule: "*/10 * * * *" jobTemplate: spec: template: spec: restartPolicy: OnFailure containers: - name: etcd-snapshot image: fideltak/etcdctl:1.0 imagePullPolicy: IfNotPresent args: - "--debug" - "--endpoints=https://[127.0.0.1]:2379" - "--cacert=/etc/kubernetes/pki/etcd/ca.crt" - "--key=/etc/kubernetes/pki/etcd/server.key" - "--cert=/etc/kubernetes/pki/etcd/server.crt" - "snapshot" - "save" - "/veritas/k8s-etcd-backup.db" volumeMounts: - mountPath: /etc/kubernetes/pki/etcd name: etcd-certs readOnly: true - mountPath: /veritas name: veritas-backup tolerations: - key: node-role.kubernetes.io/master effect: NoSchedule affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: node-role.kubernetes.io/master operator: Exists hostNetwork: true volumes: - name: etcd-certs hostPath: path: "/etc/kubernetes/pki/etcd" - name: veritas-backup persistentVolumeClaim: claimName: veritas-pvc readOnly: false③ NetBackupのクライアントコンテナからコンテナストレージ内のバックアップファイルを参照
クライアントコンテナからはバックアップファイル（k8s-etcd-backup.db）が見えている↓
root@test:/veritas# ls -la total 105529 drwxrwxrwx 1 root root 1 Feb 14 10:53 . drwxr-xr-x 1 root root 43 Feb 14 10:18 .. -rw-r--r-- 1 root root 108060704 Feb 14 10:53 k8s-etcd-backup.db④ NetBackpクライアントコンテナ経由で重複排除プールにバックアップ
あとは永続データのバックアップと同様にNetBackupでバックアップポリシーを作成し実行します。
クラウドサービスでk8sを利用する場合はマスタノードが見えないことが多いので、その場合は同様の手法でマニュフェストをバックアップしておけば安心です。
etcdのリストアの流れ
① NetBackupでetcdのバックアップデータをコンテナストレージにリストア
② Etcdで読める形式にするためのファイル展開を行うJobを実行
③ マスタノードのローカルディレクトリにリストア
今回は検証のため、etcdコンテナとして展開したデータを読み込み、正常性を確認しました。
本番環境では/var/lib/etcdの領域にリストアする必要があります。restore-sample.yamlapiVersion: v1 kind: Pod metadata: name: etcd-restore namespace: veritas labels: app: etcd-restore spec: restartPolicy: Never containers: - name: etcd-restore image: fideltak/etcdctl:1.0 imagePullPolicy: IfNotPresent args: - "--debug=true" - "--endpoints=http://[127.0.0.1]:2379" - "--name=master" - "--data-dir=/veritas/restore/etcd-from-backup" - "--initial-cluster=master=http://127.0.0.1:2380" - "--initial-advertise-peer-urls=http://127.0.0.1:2380" - "--user=root" - "snapshot" - "restore" - "/veritas/k8s-etcd-backup.db" volumeMounts: - mountPath: /veritas name: veritas-backup - mountPath: /veritas/restore subPath: restore name: veritas-backup volumes: - name: veritas-backup persistentVolumeClaim: claimName: veritas-pvc readOnly: false④ Etcdコンテナを公式手順に従って立ち上げ直す。
おわりに
いかがでしたでしょうか。
k8sの世界では作り込みが必要ですが、検証の上、サンプルコードも公開しましたのでハードルがグッと下がったかなと思います。仕組みさえできてしまえば、非常に簡単にバックアップができることを認識いただけると嬉しいです。
日々需要が加速するコンテナ界隈ですが、ベリタスはここまで考えてデータ保護をしています。
コンテナ環境も含めたデータ保護ができるベリタスにお任せください。本件の検証にはHPE様に多くのご協力をしていただいておりますのでこの場を借りて御礼申し上げます。
コンテナ環境基盤の導入・構築は是非HPE様にご相談ください！ベリタスのテクニカルイベントでの動画も是非ご覧ください！
商談のご相談はこちら
本稿からのお問合せをご記入の際には「お問合せ内容」に#GWCのタグを必ずご記入ください。ご記入いただきました内容はベリタスのプライバシーポリシーに従って管理されます。
その他のリンク
【まとめ記事】ベリタステクノロジーズ 全記事へのリンク集もよろしくお願い致します！
- 投稿日：2020-06-24T19:54:37+09:00
Kubernetes環境のバックアップ最適解！（構成編）
はじめに
エンタープライズアプリケーションをコンテナで稼働させたいという要求が日々高まっています。
エンタープライズアプリケーションにはデータの永続性が求められ、コンテナ環境もそれに対応してきました。しかしながら、永続データのバックアップやそのアプリケーションが動作するコンテナ環境自体のバックアップは現在でも課題の１つです。ベリタスとHPEは、コンテナオーケストレーションのデファクトとなりつつあるKubernetes（k8s）環境に対する最適なバックアップソリューションを作り上げました。まずは第一弾として、コンテナ環境に対してどのようなバックアップ環境を構成するのかを解説します。
NetBackup クライアントコンテナの提供
Veritas NetBackupのクライアントコンテナがDocker Hubで公開されています。
"docker certified"がつく、唯一のバックアップソリューションです。
https://hub.docker.com/_/veritas-netbackup-clientクライアントコンテナをコンテナ環境にデプロイし、シンプルで確実なバックアップをNetBackupに取得できます。
クライアントコンテナを用いた構成例
クライアントコンテナを用いた実装には3つの構成例があります。
それぞれの構成を簡単に解説します。
要件や実現したいオペレーションによって最適なものを選択することができます。Sidecar
Pod内でメインとなるコンテナを補助する役割を担うようなコンテナが存在する場合によく実装されるコンテナのデザイン方式です。NetBackupでの構成においても最も一般的な構成例となります。
主なメリット
・特定のNetBackupのクライアントとコンテナが紐づくため、運用管理が容易
・コンテナ毎にバックアップポリシーの管理ができ、わかりやすい
・リストア時も特定のコンテナデータを識別しやすい
・コンテナの世界で最も一般的な実装方法で管理がしやすい
・バックアップ管理者が責任を持ってデータの保護を行うことができるClient Share
NetBackupのクライアントコンテナが属するPodを独立させ、複数のバックアップ対象のPodから共有して構成する方式です。
主なメリット
・Podが多数の場合でもNetBackupのクライアントコンテナがリソースを多く消費しない
・Podが多数の場合でもNetBackupのクラアイントコンテナの配備が容易
・バックアップ対象側のPodオーナーはNetBackupクライアントコンテナを自分で管理する必要がない
・バックアップ管理者が責任を持ってデータの保護を行うことができるDump&Sweep
Dumpボリュームを用意しておき、その領域のデータをNetBackupクライアントコンテナ経由でバックアップしてくる方式
主なメリット
・バックアップ対象のPod管理者は自分の好きなタイミングでバックアップが可能
（自分の好きなタイミングでDumpボリュームにデータを吐くことができる。）
・Podが多数の場合でもNetBackupのクライアントコンテナがリソースを多く消費しない
・Podが多数の場合でもNetBackupのクラアイントコンテナの配備が容易
・バックアップ対象側のPodオーナーはNetBackupクライアントコンテナを自分で管理する必要がないクライアントコンテナの導入手順
クライアントコンテナはデプロイが完了すれば、今までのNetBackupと全く同じ方法でバックアップをすることができます。クライアントコンテナのデプロイに使ったYAMLをサンプルで公開しますので、参考にしてください。この手順ではsecretを用いて、証明書の配備までを自動化しています。
Podのyaml
pod.yamlapiVersion: v1 kind: Pod metadata: name: veritas-agent namespace: veritas labels: pod: veritas-agent spec: hostname: veritas-agent hostAliases: - ip: "192.168.x.x" hostnames: - "nbusvr.test.lab" volumes: - name: veritas-backup persistentVolumeClaim: claimName: veritas-pvc readOnly: false - name: client-secret secret: secretName: rsa-token-key containers: - name: nb-client image: store/veritasnetbackup/client:8.2 command: [ "/entrypoint.sh" ] args: [ "-M", "nbusvr.test.lab", "-c", "veritas-agent.test.lab" ] livenessProbe: exec: command: - /health.sh initialDelaySeconds: 60 periodSeconds: 180 volumeMounts: - mountPath: /mnt/nblogs subPath: nblogs name: veritas-backup - mountPath: /mnt/nbdata subPath: nbdata name: veritas-backup - mountPath: /veritas name: veritas-backup - mountPath: /etc/nb-secret-vol name: client-secretsecretのyaml
NetBackupでrsa_key（マスタサーバのCA証明書のフィンガープリント）とToken情報を記入する必要があります。secret.yamlapiVersion: v1 kind: Secret metadata: name: rsa-token-key namespace: veritas type: Opaque data: rsa_key:（マスタサーバのCA証明書のフィンガープリント） token: （Tokenを作成）Serviceのyaml
svc.yamlapiVersion: v1 kind: Service metadata: name: veritas-agent namespace: veritas spec: type: LoadBalancer selector: pod: veritas-agent ports: - name: pbx port: 1556 - name: vnetd-nbrntd port: 13724おわりに
次回は実践編として「どの領域をバックアップすれば良いのか」、「どのようにバックアップを取得するのか」を解説します。ベリタスのテクニカルイベントでの動画も公開しますのでお楽しみに！
商談のご相談はこちら
本稿からのお問合せをご記入の際には「お問合せ内容」に#GWCのタグを必ずご記入ください。ご記入いただきました内容はベリタスのプライバシーポリシーに従って管理されます。
その他のリンク
【まとめ記事】ベリタステクノロジーズ 全記事へのリンク集もよろしくお願い致します！
- 投稿日：2020-06-24T18:50:49+09:00
100日後にエンジニアになるキミ - 96日目 - 開発環境 - Docker について2
昨日までのはこちら
100日後にエンジニアになるキミ - 95日目 - 開発環境 - Docker について
100日後にエンジニアになるキミ - 94日目 - 開発環境 - 仮想化について
100日後にエンジニアになるキミ - 91日目 - 運用 - 監視について
100日後にエンジニアになるキミ - 90日目 - 開発 - CIについて
100日後にエンジニアになるキミ - 88日目 - データ - データ転送について
100日後にエンジニアになるキミ - 86日目 - データベース - Hadoopについて
100日後にエンジニアになるキミ - 76日目 - プログラミング - 機械学習について
100日後にエンジニアになるキミ - 70日目 - プログラミング - スクレイピングについて
100日後にエンジニアになるキミ - 66日目 - プログラミング - 自然言語処理について
100日後にエンジニアになるキミ - 63日目 - プログラミング - 確率について1
100日後にエンジニアになるキミ - 59日目 - プログラミング - アルゴリズムについて
100日後にエンジニアになるキミ - 53日目 - Git - Gitについて
100日後にエンジニアになるキミ - 42日目 - クラウド - クラウドサービスについて
100日後にエンジニアになるキミ - 36日目 - データベース - データベースについて
100日後にエンジニアになるキミ - 24日目 - Python - Python言語の基礎1
100日後にエンジニアになるキミ - 18日目 - Javascript - JavaScriptの基礎1
100日後にエンジニアになるキミ - 14日目 - CSS - CSSの基礎1
100日後にエンジニアになるキミ - 6日目 - HTML - HTMLの基礎1
本日は
Dockerの続きです。Dockerの導入方法
とりあえずこれから始めますと言う人の場合
まずDockerをダウンロードしないといけません。Dockerのインストール
インストーラーはここにあります。
イメージ(インストーラー)をダウンロードします。
Macの場合はイメージを開いて
アプリケーションのコピーして終わりです。
Dockerマークをアプリケーションフォルダにドラッグしてコピーは終わりです。
Windowsは多分インストーラーをクリックしてインストールだろうと思います。
Dockerの起動とチュートリアル
Macの場合はアプリケーション起動できます。
アプリケーションから開くと初めての場合はこんな画面になるかも知れません。
チュートリアルをやってみましょう。
Startをクリックして進みます。
先に進むとこのような画面になります。
右側にはコンソールが表示されます。
青字の部分をクリックして
githubからプロジェクトをクローンしてきます。
git clone・・・の部分をクリックするとコンソールでコマンドが実行されます。
これで自分のPCにプロジェクトが出来たかと思います。
Next Stepで次に進むと、また新しいコマンド実行が促されるので
これも青字の部分をクリックしてコンソールを動かします。
cd getting・・・の部分をクリックします。
下記のコマンドが実行され
Dockerのbuildコマンドが実行されます。
docker build -t docker101tutorial .
docker buildコマンドではDockerfileを元にしたコンテナーの起動
構成、Dockerイメージの作成までを実行します。コンソールを見ているとログがたらたら流れていくので
処理が終わるまで眺めながら・・・数分待ちます。処理が終わると
Dockerイメージが出来てると思います。
docker imagesコマンドを実行してみます。
ここではいくつかの
Dockerイメージが確認できます。
Dockerイメージとはコンテナの土台となるものです。ここからDockerのコンテナを起動していきます。
Next Stepから次のコマンドへ移ります。
docker runコマンドはコンテナを起動状態で作成します。
青字をクリックしてコマンドを実行します。
これでコンテナが起動できました。
動いているコンテナを見るには
docker ps -aを使います。
これでコンテナの起動が確認できました。
ブラウザーからアクセスしてみましょう。
localhost:80にアクセスすると
チュートリアルサイト画面を見ることができると思います。
イメージを共有するなどの際は
Docker Hubへの登録が必要なようです。
登録をするしないは自由ですのでいったんここでチュートリアルを抜けて
dockerのダッシュボード画面からも確認が行えます。
コンテナの起動、停止などもこの画面で行うこともできます。
dockerの使い方
いろいろあると思いますが
人が作った環境を使う人は1.Dockerイメージを取得
2.コンテナを作成
3.コンテナを起動と言うような使い方になり
イメージを1から作る人は1.Dockerfileを作成
2.Dockerイメージを作成
3.Dockerイメージを配布(共有)というような感じになります。
初めは用意された環境の読み込みができれば良いと思いますので
Dockerのイメージって何だっけと言うところから
抑えて行けば良いかなと思います。本当はもっともっと細かいので
まずはざっくりで良いと思います。まとめ
docker自体は覚えることが多すぎるので
言葉の意味や定義を抑えながら少しづつコマンドを覚えていきましょう。次回も引き続きdockerの内容やコマンドについて触れていきます。
君がエンジニアになるまであと04日
作者の情報
乙pyのHP：
http://www.otupy.net/Youtube：
https://www.youtube.com/channel/UCaT7xpeq8n1G_HcJKKSOXMwTwitter：
https://twitter.com/otupython
- 投稿日：2020-06-24T18:48:07+09:00
linuxでhost.docker.internalを使う (要docker-compose)
TL;DR
docker-compose.override.yamlに以下を記載docker-compose.override.yamlversion: "3.5" # docker-compose.yamlのバージョンと合わせる services: app: # host.docker.internalを使用したいサービス名 extra_hosts: - "host.docker.internal:172.101.0.1" # 下のsubnetの指定に合わせる networks: default: driver: bridge ipam: config: - subnet: 172.101.0.0/16 # 他のnetworkと被らないように指定firewall設定
firewallが動いている場合は、上記subnetからのアクセスを許可する必要があるかもしれません。
firewalldのコマンド例を記載しておきます。sudo firewall-cmd --permanent --zone=trusted --add-source=172.101.0.0/16host.docker.internal
docker for Mac, docker for Windowsでサポートされている、コンテナからホストのネットワークにアクセスするための特殊なドメイン。
macが開発者の主流になっているので、気軽にプロジェクトで使われ、その度にlinuxユーザーは悩みを抱える。Support host.docker.internal DNS name to host
Support host.docker.internal in dockerd on Linux
[RFD] add configuration option to add host.docker.internal by defaultこれらのissueによって最終的にはlinuxでも
host.docker.internalが使えるようになる予定ですが、リリースされるまでまだ少し掛かりそうなのでWorkaroundを記載しておきます。
というより、作業内容としては上述の通りなので、解説を書きます。docker-compose.override.yaml
このファイルはdocker-composeコマンドを実行した時に自動で読まれるので、レポジトリに含めたくない自分専用の設定などを書く際に重宝します。
ただし、-fオプションを使用する際は自動では読まれないので、その際にはこのファイルも一緒に指定する必要があります。extra_hosts
コンテナの
/etc/hostsに内容を追記します。networks
全てのコンテナは特に設定をしなければdefaultという名前のnetworkに属するので、ここに設定を書けば全てのコンテナに自動で反映されます。
ここで設定しているのは、default networkのサブネットです。普通であればnetworkのサブネットは、既存のnetworkとかぶらないように自動で選ばれますが、今回は固定したいため手動で選び設定します。
ホストは全てのnetworkに属し、そのIPは「サブネットマスクの一番下位のbitを1にしたもの」になるようです。（実際に試してそうっぽいと言うだけでドキュメントにそういう記載を見つけたわけではないので、もしかしたらそうならないケースもあるかもしれません。）
なので、このIPをextra_hostsに指定すればドメインを割り当てられるというわけです。
- 投稿日：2020-06-24T17:57:07+09:00
Katacoda で Docker, Kubernetes, Ansible を体験
インフラとアプリケーションの境目がなくなってきつつあります。
新しい技術は過去の経験とのすり合わせができにくかったりして、本を読んでもイメージがつきにくいことがあります。
どこから手をつけようか、そんなときに Katacoda が役にたちそうです。
Katacodaは様々なITテクノロジーをブラウザのハンズオン形式で学ぶことがができるツールです。わざわざ環境を準備しなくていいので、どこから手を付けたらいいかわからないときにお勧めです。
Docker
Dockerについては数多くのコースが用意されていて、準備された環境の中でハードルが低い状態で学習することができます。
終了したら褒めて貰えるのも嬉しいです。
Kubernetes
Kubernetesについても多くのコースが用意されています。
コースの概要と難易度、所要時間が示されていたりするので、どれを選べばいいか迷わずにすみます。
Ansible
Ansibleについても現時点では公式のものが9コース用意されています。
ビギナー向けの15分コース Ansible Review をやってみましょう。
１度目で全てを理解できないにしても、経験できる環境があるということは有難いです。
- 投稿日：2020-06-24T13:31:08+09:00
Windows10 HomeにDockerを導入してRstudioを使ってみよう
はじめに
この記事はDockerを使うのが初めての人、Dockerイメージを使ってRstudioを使いたい人に向けた導入です。今回使ったLocal環境はWindows10 Home、64bitです。Oracleのvirtual boxはインストールしなくて大丈夫です。
Dockerをインストール
下記のDockerのホームページからWindows10 Homeに対応したインストーラーをダウンロードします。
https://docs.docker.com/docker-for-windows/install-windows-home/Windows10 Homeを更新しよう
Window10 Homeのバージョンが19018以上でないとDockerはインストールできません。更新する必要があります。現在のバージョンはキーボードでWinキー＋Rを押してwinverと入力すれば確認できます。
バージョンが古い場合はアップデートが必要ですが、Windows Insider Programに登録していない人は現時点（2020年6月22日）でバージョン1909以降にアップデートできないため、登録が必要になります。登録がまだの人はWindowsの設定→更新とセキュリティ→Windows Insider Programに移動してInsiderに登録しましょう。この時Insiderの設定はスロー（推奨）にしておきましょう。登録が済んだらWindows Updateから更新します。
Dockerをインストール
インストールが進むとWSL 2
をインストールするするように勧められるので従います。このWSL 2のおかげで、Windows10 HomeでもDockerが使える仕組みです。全てのインストールが完了したらさっそく使ってみましょう。
Dockerを起動する
Windowsの検索スペースにcmdと入力しコマンドプロンプトを起動します。
dockerと入力し下の画像のようにコマンドの例がたくさん出てきたら成功です！ではさっそくdockerからRstudioを使ってみましょう。
Rstudioを使う
STEP 1 イメージの取得
コマンドプロンプトに
docker pull rocker/rstudioと打ち込みRstudioのイメージを取得します。STEP 2 仮想環境とローカルの共有フォルダを作る
下のコマンドを入力しSTEP 1で取得したイメージから仮想環境を整えます。この際、仮想環境とローカルディレクトリに共有のフォルダを作ります。なので、ローカルディレクトリ（自分のパソコン）とRstudio上でのディレクトリを入力します。
ここで少しややこしいですがWindows上のローカルディレクトリはバックスラッシュ\で設定し、rstudio上でのディレクトリにはスラッシュ/を使ってください。\はコマンドプロンプト上では¥と表示されます。docker run -e PASSWORD='パスワードを設定してください' --rm -p 8787:8787 -v C:\Users\Desktop\R\:/home/rstudio/mydesktop rocker/rstudioSTEP 3 Rstudioへ
DockerのダッシュボードからOPEN IN BROWSERをクリックするとRstudioがブラウザ上で起動します。この時IDとパスワードを聞かれますが、IDはrstudio、パスワードは先ほどのコマンドで設定したものを使います。
R version 4.0.0、私の知っている限りでは最新です。Rのアップデートを自分で行う時の煩わしさから解放されるのがDockerのいいところです。Rstudio右下のHomeにStep 2で設定したフォルダ（先ほどのコマンドではmydesktop）が出来ていれば完了です。
ちなみにブラウザを閉じるとコンテナもなくなるのでファイルは共有したローカルフォルダに保存しましょう。参考ウェブサイト
- 投稿日：2020-06-24T13:18:10+09:00
Docker運用のためのLaravelログ出力
概要
Docker運用におけるログ出力は標準出力/標準エラー出力となるが、単純にLaravel側でログを標準出力に設定しても出力されず、該当する記事も見当たらなかったため、実装した内容を記録する。
Laravelチャンネルドライバ設定
これは公式などにも出ているので問題にならないが、具体的には以下の二通りがある。
- 直接標準出力を指定するパターン
チャンネルドライバにstderrを指定する。/.envLOG_CHANNEL=stderr
- デフォルトのドライバを指定するパターン
他のドライバを内部で複数ラッピングできるので運用上こちらの方が便利。
- チャンネルドライバに
stackを指定する。
stackのドライバ指定にstderrを追加する。
/.envLOG_CHANNEL=stack/config/logging.php... 'channels' => [ 'stack' => [ 'driver' => 'stack', 'channels' => ['single', 'stderr'], 'ignore_exceptions' => false, ], ...php-fpm設定
Laravelの設定を行なっても標準出力されず、phpの設定なども行なってみたができず。。。
はっきりしたソースが見当たらなかったが、Laravelはアプリケーションサーバがphp-fpmの場合は、php-fpm経由で標準出力するらしい。
(他のアプリケーションサーバーは知りません。。。)
- php-fpm設定ファイル
www.confに以下の設定をする。www.confcatch_workers_output = yes # 標準出力を可能にする decorate_workers_output = no # php-fpmがログ出力時に吐くゴミ接頭辞を出さない
以上で、無事標準出力にエラーを出力することができた
しかし、decorate_workers_outputパラメータはphp7.3以降が有効だとのことなので、それ以前はどやって対応していたのだろう。。。
ゴミも出力することを許容せざるを得なかったのか
- 投稿日：2020-06-24T07:31:29+09:00
Windows docker終了後 シャットダウン時に｢VirtualBoxインターフェイスにアクティブな接続があります｣と表示される
exitコマンドの前に
docker-machine stop
を実行するOracle VM VirtualBoxを
使用して手動で電源OFFにもできる
※別記事で作成予定
- 投稿日：2020-06-24T00:40:06+09:00
dockerとmysqlでrails環境を構築したけどドハマリした
dockerにrails環境を作った
https://qiita.com/NA_simple/items/5e7f95ae58eec5d20e1f途中なぜか上手くいかないと思ったら、mysql-clientsがインストールできなくなっているらしい。書き換え方は下のURLを参考に。
https://qiita.com/yagi_eng/items/1368fb2a234629a0c8e7調子に乗ってすすめていると、またハマる。
terminal$ docker-compose run web rails db:create Starting postgress_db ... done Could not find activesupport-5.2.4.3 in any of the sources Run `bundle install` to install missing gems.なぜだ、、、と思ったらrubyのバージョンが違う？？
rbenvでバージョンを探しても、2.7.1が見つからず。
rbenv古い事に気づき、アップデートrbenvをアップデート
https://qiita.com/pugiemonn/items/f277440ec260b8d4fa6aからのgemも古い事に気づき、
terminal$ gem updateまだいかない、、、
bundler updateを行う。ここらへんで絶望したので時間を置く。
一旦整理して、違うサイトの最初から手順をパクる。
https://toranoana-lab.hatenablog.com/entry/2020/06/05/173658
なんと止まること無くdockerの起動、localhostにアクセス可能に！！！
よっしゃ！！！！localhost_3000Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)なんで :D
ググるとファイルが無いらしいからsudo touchで無理やり作ってる記事がちらほら。
でもファイルあるしなあ、と思いつつ削除&作成同じエラー。
？？？と思い、ここでmysql立ち上げていないことに気づく
これだ！！！と思ってterminalmysql.server startを実行するも、起動しない。
ググるとどうやらterminalsudo rm mysql.sock brew uninstall mysql brew install mysqlと、sockファイルを消してからmysqlをアンインストール→インストールで治るらしい。
mysql.sockのパスは前のエラーで判明していたので、それを消してからterminalmysql.server start…通った！！！！
これは行ったか…？
ヤッターーーーーーー！！！！！！！！！
docker理解してから構築したほうが早かったと思います。
勉強し直しましょう。自分。なにはともあれ動いてよかった
最終的な各ファイルの中身↓
gemfilesource 'https://rubygems.org' gem 'rails', '~>6'docker-compose.ymlversion: '3' services: db: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: ports: - '3306:3306' command: --default-authentication-plugin=mysql_native_password volumes: - mysql-data:/var/lib/mysql web: build: . command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'" volumes: - .:/myapp ports: - "3000:3000" depends_on: - db stdin_open: true tty: true command: bundle exec rails server -b 0.0.0.0 volumes: mysql-data: driver: localDockerfileFROM 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 \ && apt-get update -qq \ && apt-get install -y nodejs yarn \ && 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"]
