3930kmのいっぽめ

動かない... AWS の Lambda 上で Sqlite を動かしたいと思ったので試してみたが、素直に動かせなかったので動かせるようになるまでの記録を残しておく。 現象 nodejs で Sqlite を動かすために better-sqlite3 をインストールし、 AWS の Lambda にデプロイして実行すると以下のようなエラーが発生し実行ができなかった。 /lib64/libm.so.6: version `GLIBC_2.29' not found どうも nodejs 18 が動いている Amazon Linux 2 の /lib64/libm.so.6 に GLIBC_2.29 が入っていないが、 better-sqlite3 では 2.29 を使っているため実行エラーになってしまっている様子。 ちなみに Amazon Linux 2 の /lib64/libm.so.6 の確認は以下のように行った。 # Amazon Linux 2 のコンテナを起動 > docker run -it --rm --entrypoint "bash" public.ecr.aws/lambda/nodejs:18-x86_64 以下をコンテナ内で実行 > yum install binutils > strings /lib64/libm.so.6 | grep GLIBC_ GLIBC_2.2.5 GLIBC_2.4 GLIBC_2.15 GLIBC_2.18 GLIBC_2.23 GLIBC_2.24 GLIBC_2.25 GLIBC_2.26 GLIBC_PRIVATE GLIBC_2.15 ... 解決方法 AWS Lambda の nodejs 18.X ランタイムが動いている Amazon Linux 2 用に better-sqlite3 をビルドし直した。 ビルド方法 AWS Lambda nodejs 18.X の実行コンテナイメージは公開されているので、それを使ってビルドした。 今回対象としている better-sqlite3 のバージョンは 8.3.0。 Amazon Linux 2 が更新されない限り、これ以降のバージョンを使う場合で...

Amazon Linux 2 に PostgreSQL をインストールして外部のクライアントからアクセスするまでを忘れないようにメモとして残しておく。 環境 AMI Amazon Linux 2 Kernel 5.10 AMI 2.0.20221004.0 x86_64 HVM gp2 インスタンスタイプ t3a.small ストレージ 16GB EC2内での手順 sudo amazon-linux-extras install -y postgresql14 sudo yum install -y postgresql-server postgresql-devel パッケージ 説明 postgresql-server initdb や pg_ctl などのユーティリティ postgresql-devel ヘッダや pg_config などの開発関連 export PGSETUP_INITDB_OPTIONS = "--encoding=UTF8 --locale=ja_JP.UTF-8 --lc-collate=ja_JP.UTF-8 --lc-ctype=ja_JP.UTF-8" オプション 説明 --encoding initdbでPostgreSQLクラスタのデフォルト文字セット(エンコーディング) --locale ロケールのサポートはアルファベット、並び換え、数字の書式など文化的嗜好を配慮したアプリケーションを対象にします。 --lc-collate 文字列の並び換え順 --lc-ctype 文字の分類（文字とはどんなもの？大文字小文字を区別しない？） sudo postgresql-setup --initdb sudo systemctl start postgresql.service sudo systemctl enable postgresql.service 以下のコマンドで PostgreSQL が実行されているかを確認できる。 systemctl status --no-pager postgresql.service インストールが完了すると...

Pro Git について Git の教材は色々と存在していますが、公式の HP に Pro Git というドキュメントがあります。 このドキュメントはスコット・チャコン(Scott Chacon)さん、ベン・ストラウブ(Ben Straub)さんによって書かれた Git の解説書でコマンドの仕組みなどが詳細に解説された良書だそうです。 そしてこの Pro Git という本は Creative Commons Attribution Non Commercial Share Alike 3.0 license で公開、つまり無料で見れてしまう本になっています!! しかも有志によって様々な言語に翻訳をされているので英語が苦手な自分でも読めてしまう、こんなありがたいことはないですね。 以前から Git を使っていますがふわっとした理解だったので一度しっかり勉強して使いこなせるようになっていきたいです。 読んでみて勉強になったことや思ったことはこのブログにまとめていこうと思います。 因みにスコット・チャコンさんは Git 公式サイトの管理者で以前 GitHub の CIO も勤められていたらしいです。 1.1 バージョン管理に関して やっぱりファイルの管理は昔から課題があったんだなと思いました。 私が一番始めに触ったバージョン管理システム (VCS: Version Control System (Version Canri System ではない)) は svn だったので初めて git を使ったときはブランチの概念がかなり違いだいぶ混乱しました。 RCS という VCS があったことは知らなかったです。試しに wsl の Ubuntu 18.04 で rcs コマンドをたたいてみましたがインストールされていないと出たので Ubuntu にはデフォルトで入ってないみたいです。 ローカル -> 集中バージョン管理システム (CVCS: Centralized Version Control System) -> 分散バージョン管理システム (DVCS: Distributed Version Control System) と流行が変わってきて今は DVCS の Git 全盛期ですね。 コードのホスティングサイトや CI/...

この記事は以下の記事の GitHub から画像を参照する話の続きになります。 https://first-step-of-3930.blog.uttne.net/2022/03/blog-post_70.html GitHub の画像を参照する方法を変更 記事にも書きましたがこのブログでは本文や画像などのデータを全て GitHub で管理する方向で整備を行っています。 このため、記事から参照する画像などは GitHub から取得する必要があり、そのための URL を Python で作成しています。 その URL は GitHub の Raw ファイルを参照するものなのですが以下の StackExchange によるとサービスの悪用と見られかねないらしいので GitHub の静的ホスティングサービスである GitHub Pages でレポジトリを公開し、画像や css を取得する方法に変えました。 CSS file from GitHub pages sent as text/plain, needs to be text/css - StackExchange また、 GitHub Raw で css を取得しようとすると MIME タイプが text/css ではなく text/plain になってしまうので HTML の head に link を書いても読み込まれないという問題が発生したのでこれを解決するためにも GitHub Pages を使用しました。 やったこと やったことは単純で以下の2つです。 レポジトリを GitHub Pages で公開 URL の生成部分で GitHub Pages の URL を生成するように変更 GitHub Pages でレポジトリを公開する方法は多くの方が説明してくれているのでここでは省きます。 公式ページにも丁寧な解説があるのでそちらをご確認することをお勧めします。 すでにあるレポジトリを公開する場合はこの GitHub Pages サイトの公開元を設定する - GitHub Docs から見るのがいいと思います。 URL を生成する部分の変更は raw.githubusercontent.com から uttne.github.io というドメインに変更したことと...

Blogger API での画像 Blogger に記事を投稿する際、画像を一緒に投稿できたら便利だなーと Blogger の API を確認してみましたが、残念ながら画像を投稿できそうな API が見つかりませんでした。 どうも調べてみると Blogger の画像自体は Google アルバム アーカイブ に保存されているよう。 別の話になりますが、 Blogger のエディターを使ってアップロードした画像を消したくなったときはここから消せばよさそうです。 多分 Google の別のサービス (Google フォト?) の API を使用すれば多分同じことができるのだと思いますが、記事のソースである Markdown と画像が GitHub と Google アルバム アーカイブ に別れて管理されるのは美しくないので画像も GitHub に管理することにしました。 GitHub の画像の参照 GitHub のレポジトリに画像をアップロードするとその画像を参照する URL を発行してくれます。 今回はその URL をブログの記事に埋め込んで画像を表示しようと思います。 コミットした画像はその際のハッシュとリポジトリ内のパスを使って参照する URL を求めることができます。 例えばこのブログのソースを管理しているレポジトリのある画像は、以下のパラメータを組み合わせて画像のデータを参照する URL が次のように求まります。 パラメータ パラメータ 値 GitHub のレポジトリの URL https://github.com/uttne/blog.git 画像をコミットしたときのハッシュ値 3143021a9a16cb5a66b0125fdd6a77e86039cb87 リポジトリ内の画像のパス posts/00003-upload-images-test/test-image.png 求められる URL https://raw.githubusercontent.com/uttne/blog/3143021a9a16cb5a66b0125fdd6a77e86039cb87/posts/00003-upload-images-test/test-image.png raw.githubuser...

画像の投稿テスト

投稿の自動化 ブログの投稿を自動化するためにスクリプトを作成してみました。 ソースコードは ここ にあります。 投稿は Markdown で書きたかったので調べてみたら StackEdit という便利そうなツールがありましたが、やっぱり使い慣れている VSCode を使いたいと思ったので Python でスクリプトを書きました。 GitHub で記事の内容も管理できるようになったのでバージョン管理もしやすくなったし、もしも Blogger がサービス終了となっても内容が残るのでいい感じではないかと思ってます。 つまずいた所 API の使用方法 Blogger の API を使用しなければならないのでまずは開発者ドキュメントとサンプルコードを探しました。この2つは Google で検索すればすぐに見つかったのですが認証をする所でちょっと躓きました。 とりあえず認証をしなければいけないので GCP の APIとサービスで OAuth 2.0 クライアント ID を作成し、 Google API の Python ライブラリレポジトリにあった oauth-installed.md というドキュメントを参考に API にアクセスできるか試して見たのですがなぜかアクセスすることができない。 色々調べると以下のコードに問題があったようでした。 credentials = flow . run_console () Credentials を取得するコードなのですがコンソールに表示される URL にアクセスしても Error 400: invalid_request と表示されて code が取得できない。どうも redirect_uri に urn:ietf:wg:oauth:2.0:oob を設定するとダメなようでした。似たような現象で困っている人が stack overflow に 質問 を投稿されていたのでそれを参考にしました。 なぜ urn:ietf:wg:oauth:2.0:oob はだめなのかまではよくわからなかったですが、とりあえず以下のようなコードで何とか Credentials を取得できるようになったのでとりあえずはよしとします。どなたかなぜこの urn を設定できないかご存知の方がいらっしゃいましたら教えてく...