2021/01/12 現在
基本的にはここ見ればOKです
ポイント
- Railsはセマンティックバージョニング
- バグ修正は最新バージョンのみ (2021/01/12 現在、
6.1.Z
) - セキュリティFIXは、メジャーシリーズ全てと、1つ前のメジャーの一番最後のマイナーリリースに適用
- 2021/01/12 現在、
6.1.Z
、6.0.Z
、5.2.Z
- 2021/01/12 現在、
2021/01/12 現在
基本的にはここ見ればOKです
6.1.Z
)6.1.Z
、6.0.Z
、5.2.Z
設定ファイル周りについては、Amazon Linux AMI や CentOS6系以前のお話
ただし、クロックそのもの話は各Linuxでもだいたいおんなじなはず
時計。Linuxは2種類のクロックをもつ
RTC(リアルタイムクロック)とも呼ばれる。マザーボードが持つ物理的な時計
ボタン電池で電力供給され、電源OFF時にも時刻が維持され続ける
OSのソフトウェアで管理するクロック
OS起動時に、ハードウェアクロックの値を元に設定される
1970年01月01日00時00分00秒 からの経過秒数(UNIX時間) の形式で管理されている
マザーボードの機能の1つ。定期的に割り込みをかけて、システムクロックの時刻を進める
/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
true
: UTCとして解釈するtrue
: ローカルタイムとして解釈する/etc/localtime
の参照元を設定マシンを再起動したり、glibcのupdateなどで /etc/localtime
の参照元は、ZONEで指定した値に置きかわる
/etc/localtime
だけを変更しても、マシンの再起動やglibcの更新でタイムゾーンがUTCに戻る
そうならないために、 /etc/sysconfig/clock
の設定も必要
公式ドキュメントを参照
/etc/sysconfig/clock
タイムゾーンを "Asia/Tokyo"
に変える場合
ZONE="Asia/Tokyo" UTC=true
/etc/localtime
sudo ln -s /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
その後、各アプリのタイムゾーンの認識を更新するために、マシンの再起動を行う
reboot now
2020年LCLアドベントカレンダーの10日目です!
2020/12/08 に CentOS から「今後は CentOS Stream に開発リソースを集中し、CentOS 8 のEOLを2021年末とする」という発表がありました
twitterなどではいろいろな意見が出ていたのですが、私がそもそも RedHat系Linuxディストリビューションがこれまでどのように開発されていたのかキチンと把握していなかったので CentOS Stream と一緒に調べてみることにしました
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系ディストリビューション と呼ぶこともあるそうです
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は、半年に一度メジャーバージョンがupされ、おおよそ13ヶ月そのパッケージが保守されます
RHELは、RHEL 8 以降、メジャーバージョンを3年毎にupし、マイナーバージョンを半年毎にupします
また、メジャーバージョンは5年間サポートされ、その後も5年間はメンテナンスサポート(新機能の追加が無い更新)されます。さらに、その後任意の数年間「延長ライフサポート」が行われます
サポートが長いのが、RHELのウリです
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 誕生の伏線となります...
ついに CentOS Stream です。2019年に CentOS Stream 8 が発表されました
CentOS Stream は、これまでの RHEL のクローンではなく、RHELの開発サイクルに組み込まれ、 Fedora の内容を RHEL に組み込む前段階 としての役割を持っています
つまり、これまでは Fedora -> RHEL -> CentOS
という流れだったものが、 Fedora -> CentOS Stream -> RHEL
という流れになります
今後は、RHELのマイナーリリースは、CentOS Stream を噛ませて、OSSコミュニティの開発者やユーザの意見を取り入れて行われるとのことです
なお、CentOS Stream は開発者用プラットフォームという位置づけのため、本番環境での利用する性質のものではありません
そもそも CentOS の時点でも商用利用でしたら RHEL を使ったほうが良いとは思いますが...セキュリティアップデートとかもRHELの後になりますし...
開発方法の変更により、CentOSと比べて、以下のようなメリットが生まれました
今までは、RHELの修正を待つ必要がありましたが、それを待つ必要がなくなりました
これまでは、OSSコミュニティが CentOS の RHELのコードベース部分に手を入れたい場合は、Fedora を介する必要がありました。(そのための Fedora ELNというプロジェクトがあるそうです)
ただし、RHEL が Fedora のコードベースを持ってくるのは、メジャーバージョンアップの時だけなので、RHELのマイナーバージョンアップにOSSコミュニティが介入する方法はありませんでした
しかし、今後は RHEL のマイナーバージョンアップの前に CentOS Stream を介するため、このタイミングでOSSコミュニティが、RHELのマイナーバージョンアップに対して、PRや意見を出すことができるようになりました
これにより、RHELのマイナーバージョンアップに対して、意見が出せるようになったのですが、反面、RHELのベータテストをCentOSユーザにやらせるのか という意見も上がっているようです
👇 こちらのコメント欄で意見が色々出ています
Red Hat社のQAでは「CentOS Streamの方がRHELよりも先に変更が行われるため、RHELよりバグは少なく、機能は多い」と回答しています
👇 こちらの 「Q5: Does this mean that CentOS Stream is the RHEL BETA test platform now?」
CentOSは、 CentOS Stream に開発を注力するため、以下のようにするとのことです
「無償版RHEL」という認識で、CentOS を本番環境で使用していたユーザからは大きく不安の声が出ているようですね...
私も前社のオンプレ環境で使用していました。ちょっとしたオンプレのプロジェクトや社内サーバはRHELではなく、CentOSという方も多いのでは無いでしょうか
このあたりが今後どこに移行されていくか注目ですね
CentOSを本番環境で使う是非が議論されているフォーラム
(やはりセキュリティとサポートの有無について議論されていました)
「CentOSは死んだ」というやや過激な記事。こちらではCentOSの代替が議論されていました
👇 Fedora、CentOS Stream、RHEL のデリバリーの流れについて分かりやすく説明してくれています
👇 CentOSのプロジェクトの創始者がCentOS代替プロジェクト、Rocky Linuxを立ち上げ
👇 RHELのソリューションアーキテクトの人のツイート「そもそもCentOSだって定期的にupdateしないといけないし、安定した問題がない状態なんて幻想」というお話
「CentOSが他の無料ディストロより固い(or 慣れてる etc.)から使っててしょっちゅうyum update -yしてるよー」って人はCentOS Stream使ってもおおむね事故らないと思う。そうじゃない人はRockyその他に期待して……。
— Kazuo Moriwaka (@moriwaka) December 16, 2020
「バグは事実上無限にあり安定した問題がない状態など幻想の中にしかないのだ」から会話するのしんどい……
— Kazuo Moriwaka (@moriwaka) December 16, 2020
OpenSSLの最新バージョンはいくつ? 今サポートされているバージョンはどれ? いつまで? とかわからなかったのでまとめる
2020/12/10 現在
詳しくは公式を読んでください
MAJOR.MINOR.PATCH
)Dockerfileをベストプラクティスに沿って作るとそうなりがち
0〜1023 までのポートは well known port と呼ばれ、開放にroot権限が必要なため
8080は、非rootユーザがwebサーバを立てる時の使うポートと、IANAで定義されているため
--docker
オプションを使う
serverless invoke local --docker --function hoge
--docker
オプションを使うと、AWS lambda が公式に配信しているDocker でシミュレートされた Lambda 環境 ( lambci/lambda
) をつかって、serverlessをローカルで実行してくれる
lambci/lambda
の解説この lambci/lambda イメージは Lambda 環境の完全なコピーではなく、一部のファイルが欠落している可能性があることにご注意ください。
lambci/lambda
の docker hub