2018年M1のエンジニアサマーインターン挑戦結果
【だいぶ心が荒んでいた時期に書いたブログ記事を修正しました。】
挑戦した企業
- [x] pixiv summer bootcamp エンジニア(github->面接 落)
- [x] DMM エンジニア(スキルチェックシート->面接->落)
- [x] DeNA ゲーム・プロダクト開発(書類->面接(1次) -> 落)
- [o] Nagisa 2日間(サポーターズプロフィール->面接->合格)
- [x] コロプラBuild up(書類 -> 技術テスト -> 面接 ->結果待ち)
- [o] CA社 KyotoHack(サポーターズプロフィール8/9->面接8/13->合格)
自分のスキル/経歴については以下を参考にしてください。
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です。
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は色々とつまることも多く、バージョンアップによりコマンドや書き方が変わるので大変ですね。バージョンはできるだけ最新のものを使うように順次更新するようにしていくのが良いですね。
もっとスマートかもしれない資料
すぐにデプロイするための環境をつくる
はじめに
この記事は書きかけの記事です。具体的な方法を書いていません
動機
あるプログラムやサービスを作った時に、すぐに自分や誰かに試してもらいたいときがあると思います。 でもローカル環境で動くものはすぐに作れても、本番環境(ここでは、アプリをダウンロード可能な環境(app sotreなど)に置くことも含めます)で動かせる・置けるようにするということは面倒で、作成したプログラムやサービスを作るための技術とは別の技術が必要なことも多いです。そのため、例えば自分でもテストすることが面倒になったりするわけです。 なので、できるだけ簡単に本番環境へのデプロイが可能な枠組みは重要で、それを作っておきたいと考えました
Webサービスについて
ゴール: - 作成者側(未来の自分)への配慮: - 自分が主に用いるフレームワークや言語に対応したデプロイ方法の手順を記述し、APIやHPという形での公開を自動化する。できるだけ自前サーバーに載せる方法を考える - 利用者側への配慮: - リンクからすぐにアクセスできる。jsonを返すAPIなどの場合は、その情報の可視化を行うページも作成する。操作がわかるようにドキュメントも用意する必要があるので、テンプレを作成する。そのテンプレには実例のスクリーンショットを必ず載せる
スマホアプリについて
ゴール: - 作成者側(未来の自分)への配慮: - また調べます(デプロイはIDEに任せていたので、自動化の方法はよくわからない。また現時点での開発を考えていないため) - 利用者側への配慮: - リンクからすぐにダウンロードできる。ダウンロード方法が難しい場合、その手順のテンプレも記載する。操作がわかるようにドキュメントも用意する必要があるので、テンプレを作成する。そのテンプレには実例のスクリーンショットを必ず載せる