未熟学生エンジニアのブログ

TetsuFeの個人開発ブログ

TetsuFeはテツエフイー と読みます。FlutterやWeb周り全般、チーム開発について語るブログ

pymongoでdocker上のmongodbにアクセスするときのホスト名設定

はじめに

docker上でmongodbを起動して、pymongoからアクセスする設定に苦労したので備忘録的に記述例を書いておきます。

ポイント

pymongoを使う時、 client = MongoClient('ホスト名', ポート番号) のような文を書くと思うが、このホスト名をdocker-composeで指定したサービス名と同じにする必要がある。

例

version: '2'
services:
  dev:
    build: ./dev
    links:
      - mongo
    volumes:
      - ./dev:/dev

  mongo:
    image: mongo:3.6.3
    volumes_from:
      - datastore
    ports:
      - "27017:27017"
    command: --smallfiles

  datastore:
    build: ./datastore
# coding: utf-8

DATABASE_NAME = 'test_database'
COLLECTION_NAME = 'test_collection'

from pymongo import MongoClient
# ダメな例
# client = MongoClient('localhost', 27017)
# 良い例：ホスト名をdocker-composeのサービス名と合わせよう
client = MongoClient('mongo', 27017)
db = client[DATABASE_NAME]
collection = db[COLLECTION_NAME]
result = collection.insert_one({"id":1,"name": "tetsufe"})

ターミナルのコマンド履歴を$や#付きで確認する

自分が過去にやったことをメモをするときに、こんな書き方をすることがある。

$ bundle install
$ rails s

この場合、いざ成功して、「成功したこの過程をメモしたい！」となったとき、bashのhistoryコマンドが役にたつ。 しかし、単にhistoryを使うと、以下の用になってしまい、そのままコピペしただけでは使えない。

$ history
（前略）
  532  bundle install 
  533  rails s  
  534  history

メモするときには、こんな感じに出力されるとコピペするだけでメモになるので、こう表示させたい。

$ bundle install 
$ rails s

そんなときは以下のように書けば良い

$ history | awk '{$1=""; print "$" $0}'

例

$ bundle install 
$ rails s

また、# bundle installのように表示したい場合は、 $ history | awk '{$1=""; print "#" $0}'のように、printの直後の$を#に変えればOKです。

conohaVPSで間違ってログインできなくなった時の対処法

ConohaVPSでいろいろ設定をいじっていると、ログインできなくなってしまうことがあると思います。

 

## 対処法

Conohaのコントロールパネルの「コンソール」からログイン(この時はパスワード認証が設定にかかわらず使えます)して、設定を変更すればOKです。

 

## ちなみに: どんな時にそうなる？

 

例えば、

- sshの認証でパスワード認証も鍵認証も無効(というか設定失敗)にしてログアウトしてしまった

- sudo rebootしたら設定が元に戻って上の状態に

 

などの場合です。

docker-composeでデータベースを扱うときは、ホスト名＝サービス名だ。linksだ。

docker上でwebとdbというような感じでサービスを構成すると、localhost:5432みたいな書き方だとデータベースに繋がらない。

db:5432のように書こう。

また、depends_onじゃなくlinksを使おう。

web:
  links: #depends_onではダメ
    - db 
db:
   #以下略

だ。

dockerでコンテナの停止から、だいたい全部消し去るまで

はじめに

dockerをコピペ以外で初めて使って、停止・削除系のコマンドの習得に結構苦戦したので、忘れないように一連の流れのメモ。

dockerのバージョン

Docker Community Edition Version 17.12.0-ce-mac55 (23011) Channel: stable

コンテナの起動

$ docker run -it -d

とか

$ docker-compose up -d

などでやると思います

コンテナの停止

docker-composeを使った人は、

$ docker-compose stop # コンテナの停止

もしくは

$ docker-compose down # コンテナの停止と削除

docker run を使った人は

$ docker ps --no-trunc #CONTAINER_IDを表示
$ docker stop CONTAINER_ID

以下、docker-composeを使った時とdocker runを使った時の順で書いていきます

コンテナの削除

$ docker-compose rm

もしくは

$ docker rm CONTAINER_ID

イメージの削除

コンテナだけでなく、必要であればイメージも削除する必要があります （ただし、以下の操作はイメージを使用しているコンテナが停止していることが前提です）

一個ずつ消す場合
$ docker images -a
$ docker rmi IMAGE_NAME

使われていないイメージを全て消す場合
$ docker images -aq | xargs docker rmi

ボリュームの削除

ボリュームを使った人は、コンテナを消してもボリュームが残っています。 必要でなければ、毎回消しましょう

一個ずつ消す場合
$ docker volume ls -f dangling=true
$ docker volume rm VOLUME_NAME

使われていないボリュームを全て消す場合
$ docker volume ls -qf dangling=true | xargs docker volume rm

ストレージの確認

$ df -h # 削除後すぐには反映されない可能性があります

終わりに

$ docker system prune

は、結構万能に見えて消しきれていない場合もあります。
特にイメージやボリュームは消えてない時があるような気がします。確認してませんが。w

なんかdockerは色々とつまることも多く、バージョンアップによりコマンドや書き方が変わるので大変ですね。バージョンはできるだけ最新のものを使うように順次更新するようにしていくのが良いですね。

もっとスマートかもしれない資料

不要コンテナイメージの削除 | technote

すぐにデプロイするための環境をつくる

はじめに

この記事は書きかけの記事です。具体的な方法を書いていません

動機

あるプログラムやサービスを作った時に、すぐに自分や誰かに試してもらいたいときがあると思います。 でもローカル環境で動くものはすぐに作れても、本番環境（ここでは、アプリをダウンロード可能な環境（app sotreなど）に置くことも含めます）で動かせる・置けるようにするということは面倒で、作成したプログラムやサービスを作るための技術とは別の技術が必要なことも多いです。そのため、例えば自分でもテストすることが面倒になったりするわけです。 なので、できるだけ簡単に本番環境へのデプロイが可能な枠組みは重要で、それを作っておきたいと考えました

Webサービスについて

ゴール: - 作成者側（未来の自分）への配慮: - 自分が主に用いるフレームワークや言語に対応したデプロイ方法の手順を記述し、APIやHPという形での公開を自動化する。できるだけ自前サーバーに載せる方法を考える - 利用者側への配慮: - リンクからすぐにアクセスできる。jsonを返すAPIなどの場合は、その情報の可視化を行うページも作成する。操作がわかるようにドキュメントも用意する必要があるので、テンプレを作成する。そのテンプレには実例のスクリーンショットを必ず載せる

スマホアプリについて

ゴール: - 作成者側（未来の自分）への配慮: - また調べます（デプロイはIDEに任せていたので、自動化の方法はよくわからない。また現時点での開発を考えていないため） - 利用者側への配慮: - リンクからすぐにダウンロードできる。ダウンロード方法が難しい場合、その手順のテンプレも記載する。操作がわかるようにドキュメントも用意する必要があるので、テンプレを作成する。そのテンプレには実例のスクリーンショットを必ず載せる

作成の予定

- Ruby on Rails と djangoテンプレートを作成し、docker上で動く形でデプロイできるようにする

ポート関連でつまづいた話と、何かを知る・覚えるためにはつまづく必要があるよねという話

僕は液晶タブレットを持っているという話

絵も描かないのに。しかしモニターとしても使えるので、普通にモニターとして使用しています。 HUION Kamvas GT-191 5万円台で買える液タブなので安くて買いました。

閑話休題、表面上の問題

表面上の問題はVSCodeの拡張機能で起こりました。

僕は、VSCodeの拡張機能Preview on Web Serverを使っています。

これは、HTMLのリアルタイムプレビューを表示できる拡張機能で、いちいちブラウザを更新しなくていいので便利です。

いつものようにこれを使っていたのですが、いきなりプレビューが表示されなくなりました。

本当にいきなり？

実は、この問題が起こる前に、一回macがカーネルパニックを起こし、再起動しました。 これが起こった時、「あ、液タブ繋いでるからだな。」と思いました。 これを思い出して、「多分、変に再起動したからだろう。もう一回再起動すれば治るはず」と思い、再起動。でも、残念ながら治らず。

じゃあ、原因は何か？

きっと、サーバーが閉じてるんだろう。そう思って、サーバーを再起動してみました（Preview on Web Serverは、ローカルサーバーを起動、停止させることができ、そのサーバーにアクセスしてプレビューを表示しています）

$ lsof -I :8000 をすると、やはり何も表示されません。サーバーが起動してないらしい。

  • ウイルスバスターの設定確認（結局どうするかわからず諦めた）
  • Preview on Web ServerのGitHubでコード確認（意味がわからなかったので諦めた）

などしてみましたが、 なんとなく「液タブが原因では？」と気づきました。それしかもう考えられない。

解決法：液タブとの接続を切る

液タブとの接続を切ったところ、正常にサーバーが起動し、HTMLプレビューが表示されました！

ちなみにもう一度液タブをつなぎなおしたところ、そのままプレビューは表示されました。

しかし、なぜ液タブが繋がっていたらサーバーが起動できなかったのか？ それは、ポートの仕組みが関係していると考えられます。なぜかというと、液タブに接続すると、イヤホンから音がでなくなるという問題も発生しているからです。（イヤホンジャックもディスプレイも、ポート接続。イヤホンを何回か抜き差しすると治る）これと同じような理屈で、液タブが他のポートにも影響を与えていると考えられそうです。
でもなぜかはよくわからない・・・

終わりに

サーバーが起動しない！という時に、ポートの確認をするということは、実際にサーバーを起動するという機会があって、かつそこでハマらなければ身につかない知識だと思います。

最近では、dockerを使った時に複数コンテナが同じポートを使おうとして干渉していて、ポートの問題にぶち当たりましたが、dockerはそういう意味もいい機会を与えてくれるのかもしれません。ポートの衝突とか、普通一つしかサーバー起動しないのであまり遭遇しない問題だと思うので。特に個人開発では。