Dockerfileで apt-get upgrade するのは止めたほうが良いとベストプラクティスに書かれていた

Dockerfile best practices によると...

Avoid RUN apt-get upgrade and dist-upgrade, as many of the “essential” packages from the parent images cannot upgrade inside an unprivileged container. If a package contained in the parent image is out-of-date, contact its maintainers. If you know there is a particular package, foo, that needs to be updated, use apt-get install -y foo to update automatically.

docs.docker.com

雑な翻訳

親イメージの「必須」パッケージの多くは、権限のないコンテナ内ではアップグレードできないため、apt-get upgrade や dist-upgrade の実行は避けてください。親イメージに含まれるパッケージが古い場合は、そのメンテナに連絡してください。更新が必要なパッケージ foo があることがわかっている場合は、apt-get install -y foo を使って自動的に更新してください。

親イメージが必須とするパッケージ、foo を更新したい場合、自前で apt-get upgrade せずに、メンテナに連絡した上で apt-get install foo で個別にインストールすべきとのこと

ついでに apt-get upgrade と apt-get update の違い

• apt-get update: パッケージリストの更新
• apt-get upgrade: インストール済みのパッケージ更新

c5 ユーザはさっさと c5a に乗り換えたほうが良いの?

先に結論

保留で良いと思う

• 数台しか使ってないなら乗り換えてもたいして得しない (c5.large なら1台につき 95$/年 )
• 何十台もあるなら乗り換えたほうが良いかもだけど、少しだけCPUパワーが下がることを念頭に置く
• CPUが AMD系に変わることで、処理速度がおちるかもしれない

2020/08/11 にc5aが東京リージョンに上陸しましたね

aws.amazon.com

c5とc5a 何が違うの?

ざっくり、プロセッサの処理速度が少し落ちて、料金が90%になった

プロセッサの違い

Amazon EC2 C5a インスタンスは 2020 年 6 月にリリースされました。C5a インスタンスは、最大 3.3 GHz の周波数で実行される第 2 世代 AMD EPYC™ 7002 シリーズのプロセッサを搭載し、Amazon EC2 コンピューティング最適化 (C5) ファミリーのインスタンスのバリアントです。

今までのc5が Intel Xeon だったのに対して、AMD EPYC に変わり、CPUパワーが少しだけ下がった

c5.large と c5a.large とを比較すると以下のような感じに

c5.large

👆2コアの3.4GHz

c5a.large

👆2コアの3.3GHz

AMDとIntelで特性の違いってあるの?

PEXT/PDEP という命令が遅いらしいけど、それが具体的にどんな時に使われるのかはちょっと分からない

AMDの時だけ処理が遅いなーって時は、これを疑うと良いかも

umezawa.dyndns.info

料金の違い

largeのオンデマンド料金で比較した場合、c5aの方が90%ほど安い

• c5.large が 0.107USD/時間
• c5a.large が `0.096USD/時間

c5 ユーザはさっさと c5a に乗り換えたほうが良いの?

既存の c5 はそのままで、新しくサーバを立てるときには c5a を使うのが良さそう

理由

• c5.largeで 95$/年 程度と、大した額得しないので(リサーブドとか、Compute Savings Plans 使ってるともっと低い)
• 何十台もc5系を使っている会社なら、c5a に更新したほうが良いかもしれない

Linux系のパッケージのバージョン番号が古くても、セキュリティフィックスは入っている場合があるというお話

概要

Linux系のパッケージのバージョン番号が古くても、セキュリティフィックスは入っている場合がある

例えば

Debianのbuster(バージョン10)に入っている apache2 は 2.4.38

• https://packages.debian.org/ja/buster/httpd/apache2

本家の apache2 は 2.4.43 で、リリースノートを見ると、色々なセキュリティフィックスが入っている

• https://downloads.apache.org/httpd/CHANGES_2.4.43

debianのbusterのapache2は 2.4.38 だから、脆弱性が残っているの?

実はそんなことはなくて、2.4.38 にセキュリティフィックスを入れている

なんでそんなことしてるの?

Debianは安定性を重視しているため

勝手にパッケージのバージョンを上げて互換性を損なわないようにしている

そのため、互換性を維持しながら、現状のバージョンのセキュリティフィックスを入れている(これをバックポートと言う)

参考: 質問: なぜ旧バージョンのパッケージを変更しているのですか?

セキュリティフィックスが入ったかどうかは、どこで確認したら良いの?

security-tracker というBTSのようなもので管理されている

以下のように、https://security-tracker.debian.org/tracker/${CVE-番号} で状況が確認できる

• https://security-tracker.debian.org/tracker/CVE-2019-0217

自分の環境のパッケージにセキュリティフィックスが入っているかはどう確認するの?

例えば、上記の CVE-2019-0217 は、 バージョン 2.4.38-3+deb10u3 で修正されたと出ている

deb10u3 は、Debianのbuster(バージョン10)での 3 回目のupdateという意味

dpkg -l コマンドで、パッケージの詳細なバージョンが確認できるので、そこで +deb10u${x} のxが3以上ならば、 CVE-2019-0217 のセキュリティフィックスは適用済と分かる

# dpkg -l apache2
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version          Architecture Description
+++-==============-================-============-=================================
ii  apache2        2.4.38-3+deb10u3 amd64        Apache HTTP Server

自分の環境のバージョンが古い場合どうしたら良いの?

以下のコマンドでパッケージを更新すればOK

apt-get update && apt-get install ${パッケージ名}

参考

Debianで実際にバックポートをしている方の記録

security.sios.com

RHELも同様の仕組みを採用している

access.redhat.com

特定のpidの標準/標準エラー出力を確認する

$ tailf /proc/${pid}/fd/1
$ tailf /proc/${pid}/fd/2

知らなかった...流石linuxは何でもファイルだ...

Nginxのライフサイクルポリシーおぼえがき

はじめに

こんなもの見ないで原点にあたるのが良いです

www.nginx.com

Nginxのバージョニング

• stable : 安定版 と mainline : 主流版がある
• 偶数バージョンが stable
• 奇数バージョンが mainline
• 毎年4月に、mainline の最新版から分岐する
• 2020/06 現在は、 stable が 1.18、mainline が 1.19

stable と mainline の違い

• mainline はupdateやbugfix がドンドン入る
• stable は重大な修正のみ

本番で使うべきは stable と mainline どっち?

stable 一択

信頼性は高いですが、いくつかの実験的なモジュールが含まれている可能性があり、いくつかの新しいバグがある可能性もあります

docs.nginx.com

旧バージョンの安定版はサポートされないの?

最新の stable と mainline 以外は、deprecated だそうです

1.12, 13 Release時の記事

以前の安定版ブランチである 1.10 は非推奨となっており、今後はアップデートやサポートを行う予定はありません

www.nginx.com

serverless のバージョンが古いまま、lambda ruby 2.7 を使うと The security token included in the request is invalid エラーが出てハマるので最新版にしよう

というお話です

出てくるエラー

ruby 2.7 で serverless invoke を実行すると --aws-profile を設定していても The security token included in the request is invalid が出ます

Error raised from handler method
{ 
  "errorMessage": "The security token included in the request is invalid.",
  "errorType": "Function<Aws::SSM::Errors::UnrecognizedClientException>",
  "stackTrace": [
    "/var/runtime/gems/aws-sdk-core-3.94.1/lib/seahorse/client/plugins/raise_response_errors.rb:15:in `call'",
    "/var/runtime/gems/aws-sdk-core-3.94.1/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:20:in `call'",
    "/var/runtime/gems/aws-sdk-core-3.94.1/lib/aws-sdk-core/plugins/idempotency_token.rb:17:in `call'",
    "/var/runtime/gems/aws-sdk-core-3.94.1/lib/aws-sdk-core/plugins/param_converter.rb:24:in `call'",
    "/var/runtime/gems/aws-sdk-core-3.94.1/lib/aws-sdk-core/plugins/response_paging.rb:10:in `call'",
    "/var/runtime/gems/aws-sdk-core-3.94.1/lib/seahorse/client/plugins/response_target.rb:23:in `call'",
    "/var/runtime/gems/aws-sdk-core-3.94.1/lib/seahorse/client/request.rb:70:in `send_request'",
    "/var/runtime/gems/aws-sdk-ssm-1.76.0/lib/aws-sdk-ssm/client.rb:7859:in `send_command'",
    "/var/task/handler.rb:6:in `hoge'"
  ]
}

原因

serverlessのバグです

github.com

対応方法

最新版の serverless をインストールしましょう

macでMS公認の無料window10使用版を使う方法と、初期設定のメモ

事前準備

仮想マシンクライアントのVirtualBoxをダウンロードする

www.virtualbox.org

• 無料です

MS公式の動作確認用のwindows仮想マシンイメージをダウンロードする

https://developer.microsoft.com/en-us/microsoft-edge/tools%E3%81%A1/vms/

• 無料です
• 使用期限は90日
• ログインパスワードは Passw0rd!

VirtualBoxのGuest Additionsをインストール

仮想マシンと本体とのやりとりを便利にする、色々な機能をインストールする

• 仮想マシンの電源をOFFにする
• VirtualBoxの Machine -> Settings... -> Storage で新しくDVDデバイスを追加
• 仮想マシンを起動した後、devices -> Insert Guest Additions CD を選択
• 表示される手順に沿ってインストール & 再起動

日本語化 & macのキーボードを使えるようにする

こちらの (5) を参照

qiita.com

共有ディレクトリ

• VirtualBoxの Machine -> Settings... -> Shard folder から追加
• ゲストマシン側からは、ネットワークドライブとして見えるようになる

画面サイズをvirtualboxのウインドウサイズに追従させる

View -> Auto Resize Guest Display を選択

ソフトウェアアップデートで勝手に再起動しないようにする

• 仮想マシン内のwindowsの設定から、「更新とセキュリティ」を選択
• 「アクティブ時間の変更」から、作業時間を選択すると、その時間以外に再起動するようになる

スナップショットを取る

ここまでやったらスナップショットを取って、90日経ったらこのスナップショットからまた起動するようにしておけば楽