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

TetsuFeの個人開発ブログ

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

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->合格)

自分のスキル/経歴については以下を参考にしてください。

swiftfe0.hatenablog.com

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 

この場合、いざ成功して、「成功したこの過程をメモしたい!」となったとき、bashhistoryコマンドが役にたつ。 しかし、単に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 Railsdjangoテンプレートを作成し、docker上で動く形でデプロイできるようにする