kasei_sanのブログ

かせいさんのIT系のおぼえがきです。胡乱の方はnoteとtwitterへ

NATインスタンスとNATゲートウェイの料金比較メモ

料金の内訳

  • NATインスタンス
  • NATゲートウェイ
    • NAT ゲートウェイの時間単位料金
      • 東京リージョンで 0.062USD/1hour
    • NAT ゲートウェイのデータ処理料金(in/out問わず
      • 東京リージョンで 0.062USD/1GB
    • データ転送料金(NATインスタンスと同様

NATゲートウェイの料金については、くわしくはこちら

aws.amazon.com

金額的にはどのくらい差が出るの?

NATの上をどれだけデータが通るか次第なので、実測しないといけない

NATの上にどれだけデータが通るかはどうやって調べるの?

コストエクスプローラーから、インスタンスを絞り込んで、使用タイプグループ:EC2: Data Transfer – Internet (Out) EC2: Data Transfer – Internet (In) で絞り込めばわかる

くわしくはこちら

hacknote.jp

実際のところNATゲートウェイにした方が良い?

運用コストがゼロになるので、よっぽどのことがなければしたほうか良い

  • NATインスタンスのセキュリティアップデートとか、スケールアウトとか考えなくて良くなるし

Railsのメンテナンスポリシーおぼえがき

2021/01/12 現在

基本的にはここ見ればOKです

guides.rubyonrails.org

ポイント

  • Railsはセマンティックバージョニング
  • バグ修正は最新バージョンのみ (2021/01/12 現在、 6.1.Z )
  • セキュリティFIXは、メジャーシリーズ全てと、1つ前のメジャーの一番最後のマイナーリリースに適用
    • 2021/01/12 現在、 6.1.Z6.0.Z5.2.Z

Linuxの時計まわりのおぼえがき

対象OS

設定ファイル周りについては、Amazon Linux AMI や CentOS6系以前のお話

ただし、クロックそのもの話は各Linuxでもだいたいおんなじなはず

クロック周りのはなし

時計。Linuxは2種類のクロックをもつ

  • ハードウェアクロック
  • システムクロック

ハードウェアクロック

RTC(リアルタイムクロック)とも呼ばれる。マザーボードが持つ物理的な時計

ボタン電池で電力供給され、電源OFF時にも時刻が維持され続ける

システムクロック

OSのソフトウェアで管理するクロック

OS起動時に、ハードウェアクロックの値を元に設定される

1970年01月01日00時00分00秒 からの経過秒数(UNIX時間) の形式で管理されている

インターバルタイマー

マザーボードの機能の1つ。定期的に割り込みをかけて、システムクロックの時刻を進める

タイムゾーン周りの話

用語

  • UTC: 世界標準時
  • タイムゾーン: 地球上で同一の標準時を採用している地域の集合。UTC±時差 で表記される。日本標準時ならば UTC+9
  • ローカルタイム: タイムゾーンで示される現地時刻

Linuxでのタイムゾーンの設定方法

/usr/share/zoneinfo に各タイムゾーンの設定ファイルが格納されている

  • 東京ならば、 /usr/share/zoneinfo/Asia/Tokyo

/etc/localtime に上記のタイムゾーンの設定ファイルと同様のものをおけば、それがシステムのタイムゾーンとなる

ln -s /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

date コマンドなどの時刻を表示するコマンドは、/etc/localtime の設定を見て、システムクロックからローカルタイムを計算する

ハードウェアクロックのタイムゾーン

ハードウェアクロック自体はタイムゾーンを持たないが、ハードウェアクロックの値の解釈を設定することが可能

/etc/sysconfig/clock で設定可能

ZONE="Asia/Tokyo"
UTC=true
  • UTC: ハードウェアクロックの値の解釈
    • true : UTCとして解釈する
    • true : ローカルタイムとして解釈する
  • ZONE: /etc/localtime の参照元を設定

マシンを再起動したり、glibcのupdateなどで /etc/localtime の参照元は、ZONEで指定した値に置きかわる

参考

park12.wakwak.com

www.atmarkit.co.jp

Amazon Linux AMI でのタイムゾーンの変更方法

Amazon Linux AMI でのタイムゾーンの変更方法

先に結論

/etc/localtime だけを変更しても、マシンの再起動やglibcの更新でタイムゾーンがUTCに戻る

そうならないために、 /etc/sysconfig/clock の設定も必要

手順

公式ドキュメントを参照

docs.aws.amazon.com

/etc/sysconfig/clock

タイムゾーンを "Asia/Tokyo" に変える場合

ZONE="Asia/Tokyo"
UTC=true

/etc/localtime

sudo ln -s /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

その後、各アプリのタイムゾーンの認識を更新するために、マシンの再起動を行う

reboot now

Red Hat系Linuxディストリビューションの歴史とCentOS Streamについて調べた

f:id:kasei_san:20201210081549j:plain

2020年LCLアドベントカレンダーの10日目です!

qiita.com

経緯

2020/12/08 に CentOS から「今後は CentOS Stream に開発リソースを集中し、CentOS 8 のEOLを2021年末とする」という発表がありました

news.mynavi.jp

twitterなどではいろいろな意見が出ていたのですが、私がそもそも RedHat系Linuxディストリビューションがこれまでどのように開発されていたのかキチンと把握していなかったので CentOS Stream と一緒に調べてみることにしました

そもそものはじまり Red Hat Linux

Red Hat Linux は 1995年にRed Hat社から配布されました。当時は企業がサポートするLinuxディストリビューションの草分け的存在だったそうです。また、サポートが限定された無償版も配布されていました

特徴は、パッケージ管理システムに RPM (RPM Package Manager) を使用していることです。RPM はもともとは Red Hat Package Managerという名前で、Red Hat社が開発したものでした

RPMは、Red Hat 系以外のディストリビューション (SUSE Linux や Vine Linux) にも採用されており、それらをまとめて、 RPM系ディストリビューション と呼ぶこともあるそうです

エンタープライズ専門の Red Hat Enterprise Linux(RHEL) と コミュニティ主導の Fedora

2003年、Red Hat社は Red Hat Linux の開発を中止し、今後はエンタープライズ専門の Red Hat Enterprise Linux を開発すると発表しました (当時、Red Hat Linux はマイナーアップデートでもカーネルやライブラリの互換性が失なわれるなど、商用利用には少々難があったそうです。そのための方針転換のようですね)

その際、無償版 Red Hat Linux は Red Hat社が支援するコミュニティ Fedora Project が提供するLinuxディストリビューション。 Fedora に引き継がれました

Fedoraが最新の技術を積極的に取り込み、その成果が RHEL に反映される という流れがここから生まれました

Fedora と RHELのリリースサイクルと保守期間

余談ですが、Fedora と RHEL のバージョンは直接対応していません

Fedoraは、半年に一度メジャーバージョンがupされ、おおよそ13ヶ月そのパッケージが保守されます

fedoraproject.org

RHELは、RHEL 8 以降、メジャーバージョンを3年毎にupし、マイナーバージョンを半年毎にupします

また、メジャーバージョンは5年間サポートされ、その後も5年間はメンテナンスサポート(新機能の追加が無い更新)されます。さらに、その後任意の数年間「延長ライフサポート」が行われます

サポートが長いのが、RHELのウリです

access.redhat.com

RHELの無償版クローン(と認識されている) CentOS

RHELはエンタープライズ向けのOSとなりましたが、ソースコード自体はOSSのため公開されていました。そこから 商標や商用パッケージを除いてビルドしたものが CentOS です

CentOS 自体はRed Hat社とは関係ないコミュニティ主導のプロジェクトでしたが、2014年にRed Hat社が支援を表明。CentOSのコアメンバーがRed Hat社に入社したそうです

CentOS は RHELの無償版クローンと認識されていますが、公式は「CentOS Linux is NOT a clone of Red Hat® Enterprise Linux」と否定しており、CentOSの独自機能repositoryもあります。ただし、RHEL由来のコードは変更されないようにしているらしいです

そういった経緯があるため、CentOS を使っていて Fedora や RHEL 由来の不具合があった場合、上流プロジェクトでの修正を待つ必要であります。そのため、CentOSには、 変更の反映が遅い という欠点があります。そして、これが CentOS Stream 誕生の伏線となります...

Fedora と RHEL の橋渡しをする CentOS Stream

ついに CentOS Stream です。2019年に CentOS Stream 8 が発表されました

wiki.centos.org

CentOS Stream は、これまでの RHEL のクローンではなく、RHELの開発サイクルに組み込まれ、 Fedora の内容を RHEL に組み込む前段階 としての役割を持っています

つまり、これまでは Fedora -> RHEL -> CentOS という流れだったものが、 Fedora -> CentOS Stream -> RHEL という流れになります

今後は、RHELのマイナーリリースは、CentOS Stream を噛ませて、OSSコミュニティの開発者やユーザの意見を取り入れて行われるとのことです

なお、CentOS Stream は開発者用プラットフォームという位置づけのため、本番環境での利用する性質のものではありません

そもそも CentOS の時点でも商用利用でしたら RHEL を使ったほうが良いとは思いますが...セキュリティアップデートとかもRHELの後になりますし...

CentOS Stream のメリット

開発方法の変更により、CentOSと比べて、以下のようなメリットが生まれました

Fedora由来の不具合やセキュリティfixの高速化

今までは、RHELの修正を待つ必要がありましたが、それを待つ必要がなくなりました

OSSのコミュニティがRHELのマイナーリリースに貢献できるようになった

これまでは、OSSコミュニティが CentOS の RHELのコードベース部分に手を入れたい場合は、Fedora を介する必要がありました。(そのための Fedora ELNというプロジェクトがあるそうです)

t.co

ただし、RHEL が Fedora のコードベースを持ってくるのは、メジャーバージョンアップの時だけなので、RHELのマイナーバージョンアップにOSSコミュニティが介入する方法はありませんでした

しかし、今後は RHEL のマイナーバージョンアップの前に CentOS Stream を介するため、このタイミングでOSSコミュニティが、RHELのマイナーバージョンアップに対して、PRや意見を出すことができるようになりました

これにより、RHELのマイナーバージョンアップに対して、意見が出せるようになったのですが、反面、RHELのベータテストをCentOSユーザにやらせるのか という意見も上がっているようです

👇 こちらのコメント欄で意見が色々出ています

t.co

Red Hat社のQAでは「CentOS Streamの方がRHELよりも先に変更が行われるため、RHELよりバグは少なく、機能は多い」と回答しています

👇 こちらの 「Q5: Does this mean that CentOS Stream is the RHEL BETA test platform now?」

t.co

CentOS と CentOS Stream の今後

CentOSは、 CentOS Stream に開発を注力するため、以下のようにするとのことです

  • CentOS 9: リリースしない。CentOS Stream 9 がリリースされる
  • CentOS 8: 2021年末でEOL。CentOS Stream 8 への移行を推奨
  • CentOS 7: 以前からの予定通り、2024/6末でEOL

まとめ

「無償版RHEL」という認識で、CentOS を本番環境で使用していたユーザからは大きく不安の声が出ているようですね...

私も前社のオンプレ環境で使用していました。ちょっとしたオンプレのプロジェクトや社内サーバはRHELではなく、CentOSという方も多いのでは無いでしょうか

このあたりが今後どこに移行されていくか注目ですね

おまけ

CentOSを本番環境で使う是非が議論されているフォーラム

(やはりセキュリティとサポートの有無について議論されていました)

forums.centos.org

「CentOSは死んだ」というやや過激な記事。こちらではCentOSの代替が議論されていました

  • Oracle Linux (こちらも RHELベースなんですね) や Ubuntu LTS という意見が出ていました

lwn.net

2020/12/16 追記

👇 Fedora、CentOS Stream、RHEL のデリバリーの流れについて分かりやすく説明してくれています

rheb.hatenablog.com

👇 CentOSのプロジェクトの創始者がCentOS代替プロジェクト、Rocky Linuxを立ち上げ

japan.zdnet.com

👇 RHELのソリューションアーキテクトの人のツイート「そもそもCentOSだって定期的にupdateしないといけないし、安定した問題がない状態なんて幻想」というお話

OpenSSLのリリースストラテジを調べた

OpenSSLの最新バージョンはいくつ? 今サポートされているバージョンはどれ? いつまで? とかわからなかったのでまとめる

先に結論

2020/12/10 現在

  • 最新版: OpenSSL 1.1.1 (LTS)
  • サポートされているバージョン
    • 1.1.1 〜 2023/09/11
    • 1.0.2 サポート切れだが、セキュリティfix については有料サポートで対応
    • それ以外はサポート終了

リリースストラテジについて

詳しくは公式を読んでください

www.openssl.org

  • 最新は1.1.1(LTS)。次のリリース予定は3.0.0
  • 3.0.0 から、セマンティックバージョニング になる予定(MAJOR.MINOR.PATCH )
  • LTS(Long Term Support)は、最低5年サポート、4年に1回LTSが指定される
  • 通常バージョンは、最低2年サポート
  • サポート終了年は、セキュリティfixのみ提供
  • プレミアムサポート を受けることで、EOLになった最後のTLSのセキュリティfixを受けることができる

root権限を持たないユーザで 80番ポートを開放しようとすると怒られる理由

Dockerfileをベストプラクティスに沿って作るとそうなりがち

docs.docker.com

理由

0〜1023 までのポートは well known port と呼ばれ、開放にroot権限が必要なため

そういう場合に8080を選ぶ理由

8080は、非rootユーザがwebサーバを立てる時の使うポートと、IANAで定義されているため

www.iana.org