山ｐの楽しいお勉強生活

勉強の成果を垂れ流していきます

通信速度が原因で「apt-get」が失敗する事がある

Linux

タイトルだけ見るとそりゃそうだろという話ではあるのですが、いきなり失敗するようになってかなりハマったのでメモ。 そもそも通信速度が原因という事に気づくまでにかなりの時間がかかった。

参考までに、状況が発生した環境で通信速度を調べたところ、1Mbps位でした。（ fast.com で測定）

解決方法

apt-getのオプションでタイムアウトを指定する。

apt-get -o Acquire::http::Timeout="300" update

※指定時間の単位は「秒」との事

設定ファイルに書く場合

設定ファイルでの指定も可能（後述するがコマンドでのオプション指定よりこちらの方が良い）

  • ファイルPATH : /etc/apt/apt.conf.d
  • ファイル名 : 99timeout 何でも良いと思われる
Acquire::http::Timeout "300";
Acquire::ftp::Timeout "300";

Dockerfile

今回はdocker内で発生したため、Dockerfileのサンプルをメモ

FROM ubuntu:18.04

RUN /bin/echo -e "Acquire::http::Timeout \"300\";\n\
Acquire::ftp::Timeout \"300\";" >> /etc/apt/apt.conf.d/99timeout

RUN rm -rf /var/lib/apt/lists/* \
    && apt-get update \
    && apt-get -y install wget

※参考 : Dockerfileで複数行を改行付きでechoする際にハマったので共有しておきます ※ubuntuのデフォルトシェルであるdashのbuild inされているechoだと echo -e は使えないので注意。（-e がそのままファイルに出力されてoptionエラーになる）

ログ

C:\Users\yamap55>docker run --rm -it ubuntu:18.04 /bin/bash
root@0bbdb818123f:/# apt-get update
Get:1 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Get:2 http://security.ubuntu.com/ubuntu bionic-security/restricted amd64 Packages [31.0 kB]
Get:3 http://security.ubuntu.com/ubuntu bionic-security/multiverse amd64 Packages [7641 B]
Get:4 http://security.ubuntu.com/ubuntu bionic-security/universe amd64 Packages [824 kB]
Get:5 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages [836 kB]
Get:6 http://archive.ubuntu.com/ubuntu bionic InRelease [242 kB]
Get:7 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
Get:8 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
Get:9 http://archive.ubuntu.com/ubuntu bionic/multiverse amd64 Packages [186 kB]
Get:10 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages [1344 kB]
Ign:11 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
Get:12 http://archive.ubuntu.com/ubuntu bionic/restricted amd64 Packages [13.5 kB]
Get:13 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages [1128 kB]
Get:14 http://archive.ubuntu.com/ubuntu bionic-updates/restricted amd64 Packages [44.7 kB]
Get:15 http://archive.ubuntu.com/ubuntu bionic-updates/multiverse amd64 Packages [11.7 kB]
Get:16 http://archive.ubuntu.com/ubuntu bionic-updates/universe amd64 Packages [1351 kB]
Get:17 http://archive.ubuntu.com/ubuntu bionic-backports/main amd64 Packages [2496 B]
Get:18 http://archive.ubuntu.com/ubuntu bionic-backports/universe amd64 Packages [4247 B]
Ign:11 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
Ign:11 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
Err:11 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
  Connection failed [IP: 91.189.88.24 80]
Fetched 6278 kB in 3min 24s (30.8 kB/s)
Reading package lists... Done
E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/bionic/universe/binary-amd64/Packages  Connection failed [IP: 91.189.88.24 80]
E: Some index files failed to download. They have been ignored, or old ones used instead.

※ミラーに変更してもほぼ変わりませんでした

メモ

ログに出力されているURLについて

ログに出ている http://archive.ubuntu.com/ubuntu/dists/bionic/universe/binary-amd64/Packages にアクセスすると404になるため、サーバ側のエラーとかURLが変わったとか考えてしまった。 どうやら内部的には「Packages.gz」（もしくは「Packages.xz」）を取得しているようでこちらは存在する。（ 親ディレクトリを確認するとわかる）

updateだけオプション指定してもinstallで同じように落ちるかも

updateで現象が発生した場合、コマンド実行時のオプションで解決したくなるが、実際にはupdateだけで終わる事はなく、その後installで同じように現象が発生する事となる。 勿論install 時にもオプション指定すれば解決ではあるが、このオプションが必要な場合は設定ファイルを配置するのがベターと思われる。（httpで指定が必要な場合、ftpも指定しておいた方が無難）

参考

エンジニアとして一番大事だと思う事

ポエム

ドアカン Advent Calendar 2019の24日目の記事になります。
昨日はYoshihiko Morikawaさんのフィルムカメラの話です。熱いですね。*1

はじめに

いつの間にかITエンジニアとして若手からシニアと言う立場になってきた今日この頃です。（IT業界歴10年ちょっと） 社会人になりたての方やエンジニア歴が浅い方と話をする際に、エンジニアとして大事なことは？みたいな話をしたりします。 先日、そんな話をした時にうまく話すことができなかったので自分の思いを書いておこうと思います。 まぁ、俗に言うポエムです。

一番大事だと思う事

私はエンジニアとして一番大事だと思うのは「尊敬する人を作る事」だと考えています。

尊敬とは色々意味にとれますが、自分が将来この人のようになりたいと強く思う人という感じです。 ここで大事なのは、自分が目指すかどうか、なれるかどうか。

世の中には天才という方がいて、凄いと思うし憧れるが絶対に自分はなれない人という人がいますが、そういう人は該当しません。

つまり、尊敬する人とは、今は自分の力では及びないが、いつかは辿り着きたい目標である存在です。

なんで大事？

なぜ、尊敬する人は大事なのかというと、自分が成長できるから。

  1. 人は目標があると頑張れます。
  2. 頑張ると成長します。
  3. 成長すると褒めてくれます。
  4. 褒められると頑張ります。

っという良い循環が発生するからです。 常に意識し、良いところは学んでいく。（そうでない所は見ないふり） そして、いつか横に並ぶ事を夢見て一歩づつ進みましょう。必ず自分の成長に繋がります。

尚、3つめは異論がありそうですが、尊敬していることを伝え、頑張っていることを伝えたら必ず褒めてくれます。 自分を尊敬してくれている人は可愛く見えますし、その人が頑張っていたら褒めるに決まっている。アピール大事。

尊敬される側も成長する（はず）

自分を尊敬している人が頑張っている ↓ 自分も頑張らないと！ ↓ 成長する

っとなるはず。

私の場合

IT業界で最初に所属した会社の先輩（上司）が尊敬する人になります。 この方が上司になった時の私はどうしようもない方のITエンジニアでした。自分で勉強することもなく、指示されたことを作業するだけだったと思います。また、ずっと現場常駐だった事もあり社内で付き合いがある人もいない状態でした。当然評価も良くなかったでしょう。 そんな私を指導してくれたのがこの先輩です。

所属会社は典型的なn次請けSIerで、かなりの割合で外部会社に常駐しておりました。当然帰属意識も薄く、会社の改善や技術交流などは全く行われておりません。 そんな中孤軍奮闘して勉強会やLT会などを開催している方でした。

IT関連の情報収集の仕方から、LT資料の作り方、blogの書き方、エンジニアとして生きていくにはといった所までほんと基礎の基礎から教えていただきました。

特に最初のうちはこの方も残業続きで土日も出勤している中で、週1帰社した上で22時までMTGと称した上記の指導などをして頂きました。今から考えてもほんと頭が上がりません。

その後、先輩も私も転職しましたが、もくもく会など各種イベントに誘って頂き、現在でも私に影響を与えてくれております。

おわりに

冒頭にも記載しましたが、この記事はドアカン Advent Calendar 2019の24日目の記事になります。 このアドベントカレンダーのテーマは「自分の好きなこと」です。

私が大好きな先輩が楽しいクリスマスを迎えられますように。

*1:このアドベントカレンダーはみんな熱すぎる

GitHub ActionsでGitHub Package RegistryにDocker Imageをpushする

GitHub docker

前の記事では手動でGithub Package RegistryにDocker Imageをpushしましたが、実際にはそんなの手でやってられません。こういう事はCIにやらせましょう。

GitHub Actions及びGitHub Package Registryは正式公開されたばかりだからか、情報が少なかったのでメモ。
特に docker login については個人ユーザに紐づく方法しかみつからないので、結構ハマる方がいるはずです。

結論

以下のようにログインユーザ及びパスワード（トークン）を指定して、docker login すればOK

    - name: Push to Github Package Registry
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: |
        docker login docker.pkg.github.com -u ${GITHUB_ACTOR} -p ${GITHUB_TOKEN}
        docker tag original docker.pkg.github.com/yamap55/python_dev_env/original:latest
        docker push docker.pkg.github.com/yamap55/python_dev_env/original:latest

設定ファイル全て

name: Build Dockerfile and Push Github Package Registry
on:
  push:
    branches:
      - develop

jobs:
  build-and-push:
    runs-on: ubuntu-18.04
    timeout-minutes: 300
    steps:
    - uses: actions/checkout@v1

    - name: Build Image
      run: |
        cd docker/ && docker build -f Dockerfile_original.dockerfile -t original .

    - name: Push to Github Package Registry
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: |
        docker login docker.pkg.github.com -u ${GITHUB_ACTOR} -p ${GITHUB_TOKEN}
        docker tag original docker.pkg.github.com/yamap55/python_dev_env/original:latest
        docker push docker.pkg.github.com/yamap55/python_dev_env/original:latest

他のファイル構成などは以下を参照
https://github.com/yamap55/python_dev_env

参考

GitHub Package RegistryにDocker imageを格納する

docker GitHub

公式のドキュメントでうまくいかなかったものの、検索しても記事がみつからなかったのでメモ。 （GitHub Actionsでのサンプルはいくつもあったが、手動でのサンプルがみつからなかった。）

※わかってる人なら特に記事にする事でもないので、サンプルがなかっただけという話。

GitHub Package Registryとは

この記事見ていてわからない人はいないかもですが一応記載。

GitHub Packages is a software package hosting service that allows you to host your software packages privately or publicly and use packages as dependencies in your projects.

https://help.github.com/en/github/managing-packages-with-github-packages/about-github-packages

GitHub Package Registryとはソフトウェアパッケージのホスティングサービスです。 2019年5月にβがはじまり、11/13？に正式版になりました。

2019/12/23現在ではnpm,gem,mvn,gradle,docker,dotcetをサポートしています。（詳細は公式ページ参照）

手順

基本的に公式ドキュメント通りです。

  1. トークンの作成
  2. docker login
    • docker login docker.pkg.github.com -u USERNAME -p TOKEN
    • 例 : docker login docker.pkg.github.com -u yamap55 -p 8982f91d09e95dda471d67ff9f68408eed9adc8c
  3. docker build
    • docker build -t docker.pkg.github.com/OWNER/REPOSITORY/IMAGE_NAME:VERSION PATH
    • 例 : docker build -t docker.pkg.github.com/yamap55/python_dev_env/dev-python:1.0 .
  4. docker push
    • docker push docker.pkg.github.com/OWNER/REPOSITORY/IMAGE_NAME:VERSION
    • 例 : docker push docker.pkg.github.com/yamap55/python_dev_env/dev-python:1.0
  5. 確認

imageを使用する

  • docker pull
    • docker pull docker.pkg.github.com/yamap55/python_dev_env/dev-python:1.0
  • dockerfile
    • FROM docker.pkg.github.com/yamap55/python_dev_env/dev-python:1.0

参考

Windowsで今まで動いていたdocker runが失敗する

docker

あまりわかってないけど、解決した & 日本語の情報がみつからなかったのでメモ

エラーメッセージ

SECURITY WARNING: You are building a Docker image from Windows against a non-Windows Docker host. All files and directories added to build context will have '-rwxr-xr-x' permissions. It is recommended to double check and reset permissions for sensitive files and directories.
Run: docker run -a STDOUT -a STDERR --mount type=bind,source=c:/work/github/python_dev_env,target=/workspaces/python_dev_env,consistency=consistent -l vsch.quality=stable -l vsch.remote.devPort=0 -l vsch.local.folder=c:\work\github\python_dev_env -u vscode --entrypoint /bin/sh vsc-python_dev_env-78a41ebd12f13d8077d12b38bafdcbc8 -c echo Container started ;  while sleep 1; do :; done
C:\Program Files\Docker\Docker\Resources\bin\docker.exe: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /host_mnt/c/work/github/python_dev_env.
See 'C:\Program Files\Docker\Docker\Resources\bin\docker.exe run --help'.
Failed: Starting the development container
Command failed: C:\Program Files\Docker\Docker\Resources\bin\docker.exe run -a STDOUT -a STDERR --mount type=bind,source=c:/work/github/python_dev_env,target=/workspaces/python_dev_env,consistency=consistent -l vsch.quality=stable -l vsch.remote.devPort=0 -l vsch.local.folder=c:\work\github\python_dev_env -u vscode --entrypoint /bin/sh vsc-python_dev_env-78a41ebd12f13d8077d12b38bafdcbc8 -c echo Container started ;  while sleep 1; do :; done

※1つ目のWARNINGは関係ないかも

対応方法

  • Docker desktop起動して、パスワード再入力
  • Shared Drivesを一旦解除して、再度設定

原因

  • パスワード変更

参考

GitHubのマージ済のブランチをGitHub Actionsで定期的に削除する

GitHub

追記（2019/10/28）

GitHubのリポジトリ設定にマージ完了後にブランチを削除する設定がありました。（2019/07/31に追加されたらしいです。）よって、GitHub Actionsなんて使用せずにリポジトリの設定を変更しましょう！

help.github.com

はじめに

プルリク後のブランチ削除忘れってありますよね。気づいたらマージ済みのブランチが山のようにあったり。

で、今までは「GitHubのマージ済のブランチをCircleCIで定期的に削除する」を参考にCircleCIを使用していたのですが、GitHub Actionsでできるのでは？と思ったので調査したメモです。

面倒な設定やGitHub連携なども不要なので、プルリクを使うリポジトリには必ず入れる位でも良いかも？

一言で

「branch-cleanup-action」を見てください

手順とか

  • GitHub Actionsを有効にする
  • リポジトリのメニューに「Actions」が表示されていることを確認
  • Actions → Set up a workflow yourselftをクリック
    • 既にGitHub Actionsで何か動いている場合には「Actions → New workflow → Set up a workflow yourselft」
  • ファイル名を「pull_request-branch_cleanup.yml」に変更（main.ymlでも問題はないが。。。）
  • コードを以下のように設定
on:
  pull_request:
    types: [closed]
name: Branch Cleanup
jobs:
  build:
    name: branch-cleanup-action
    runs-on: ubuntu-latest
    steps:
    - name: branch-cleanup
      uses: jessfraz/branch-cleanup-action@master
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  • Start commit → コミットメッセージ入力 → Commit new file

※この設定自体をプルリクにしたい場合には、「 .github/workflows/pull_request-branch_cleanup.yml 」に上記の設定書いてプルリクすればよろし。

参考URL

setuptoolsがsetup.cfgを読んでくれない

Python

現象

Pythonでsetuptoolsを使用してwheelファイルを作成しようとしたが、自動的に読んでくれるはずの「setup.cfg」を読んでくれない。

※setup.pyで「setup(name='hoge')」などと指定すると正しく動作する
※正確には、license_fileなどで存在しないファイルを指定するとエラーになるので読んでくれているが、wheelファイル作成時に使用してくれない。

結論

setuptoolsのバージョンが低い

※setuptools 30.3.0から読んでくれるようになったらしい

確認

pip list
pip list -o # 更新があるライブラリのみ

アップデート

pip install --upgrade setuptools

何故発生したか

  • setuptoolsはPythonに付随してくるので、最新版のPythonを使用すればこの事象は発生しない。
    • 意図的にバージョン下げれば発生する？（動かない気もするが。）
  • 今回はvenvでPython3.5.2を使用していたため、3.5.2に付随したsetuptoolsのバージョンが仮想環境に入り、本事象が発生した。
    • 正確にはpipに依存するsetuptoolsか？

今後の対応

最初に環境を作る際に以下のようにアップグレードを行う！

mkdir hoge
cd hoge
pyenv local 3.5.2
python -m venv .venv
.venv\Scripts\activate.bat
python -m pip install --upgrade pip setuptools