ホーム 記事一覧 ブック DH週間トピックス 検索 このサイトについて
English
CloudFront + App Runner で 404 エラーが発生する問題の調査記録

CloudFront + App Runner で 404 エラーが発生する問題の調査記録

はじめに AWS App Runner で Cantaloupe(IIIF画像サーバー)をホストし、その前段に CloudFront を配置しようとしたところ、CloudFront 経由でアクセスすると全てのリクエストが 404 エラーになる問題に遭遇しました。 本記事では、問題の原因調査から試した解決策、そして結論までを記録します。 環境 アプリケーション : Cantaloupe 5.0.5(IIIF画像サーバー) ホスティング : AWS App Runner CDN : Amazon CloudFront リージョン : ap-northeast-1(東京) 問題の概要 症状 アクセス方法 結果 App Runner に直接アクセス 200 OK CloudFront 経由でアクセス 404 Not Found 確認したこと CloudFront 経由で 404 が返る際、レスポンスヘッダーに server: envoy が含まれていました。これは App Runner の内部プロキシ(Envoy)に到達していることを示しています。 $ curl -I https://xxxxx.cloudfront.net/ HTTP/2 404 server: envoy x-cache: Error from cloudfront つまり、CloudFront → App Runner の通信は成功しているが、App Runner 内部でリクエストがアプリケーション(Cantaloupe)に転送されていないことがわかりました。 ...

AWSのRoute 53で設定したレコードを、さくらレンタルサーバで使用する(共有SSL)

AWSのRoute 53で設定したレコードを、さくらレンタルサーバで使用する(共有SSL)

概要 AWSのRoute 53で設定したレコードを、さくらレンタルサーバで使用する備忘録です。加えて、Let’s Encryptを用いて、無料SSLを使用します。 さくらレンタルサーバ ドメイン/SSLにアクセスして、「ドメイン新規追加」ボタンを押します。 画面下部の「他社で取得したドメインを移管せずに使う」の「追加」ボタンを押します。 独自ドメインを入力して、「追加」ボタンを押します。以下の例では、「aaa.example.org」としています。 追加後、追加したドメイン名の「設定」>「DNSレコード設定」を押し、AレコードのIPアドレスを控えます。 AWSのRoute 53 先ほど控えたIPアドレスを使って、レコードを追加します。 さくらレンタルサーバ SSLの設定を行います。 「SSL証明書の種類を選択」ボタンを押します。 「Let’s Encrypt (無料SSL)」の「利用する」ボタンを押します。 設定後、以下のような画面になります。少し待ちます。 その後、ドメイン設定において、以下のように設定します。 さらに、それぞれのドメインに対して、「WEB公開フォルダ」を設定することで、ルートディレクトリを変更することができました。 まとめ AWSのRoute 53以外でも同様の手続きを行うことができると思います。 間違っている点もあるかもしれませんが、さくらレンタルサーバでの独自ドメインおよびSSLの利用にあたり、参考になりましたら幸いです。

iiif-prezi3を使って、動画に目次を付与する

iiif-prezi3を使って、動画に目次を付与する

概要 iiif-prezi3を使って、動画に目次を付与する方法に関する備忘録です。 セグメントの検出 Amazon Rekognitionのビデオセグメントの検出を用います。 https://docs.aws.amazon.com/ja_jp/rekognition/latest/dg/segments.html 以下などでサンプルコードが公開されています。 https://docs.aws.amazon.com/ja_jp/rekognition/latest/dg/segment-example.html 使用するデータ 『県政ニュース 第1巻』(県立長野図書館)を使用します。 https://www.ro-da.jp/shinshu-dcommons/library/02FT0102974177 マニフェストファイルへの反映 以下の記事などを参考に、マニフェストファイルが作成済みであるとします。 以下のようなスクリプトにより、マニフェストファイルにvttファイルを追加します。 from iiif_prezi3 import Manifest, AnnotationPage, Annotation, ResourceItem, config, HomepageItem, KeyValueString #| export class IiifClient: def load_manifest(self, manifest_path): with open(manifest_path, "r") as f: manifest_json = json.load(f) manifest = Manifest(**manifest_json) return manifest def add_segment(self, manifest_path): manifest = self.load_manifest(manifest_path) path = f"{self.input_dir}/output_segment.json" with open(path, "r") as f: data = json.load(f) range_id = f"{self.prefix}/range" range_toc = manifest.make_range( id=f"{range_id}/r", label="Table of Contents" ) canvas_id = manifest.items[0].id for s in data["Segments"]: s_type = s["Type"] if s_type != "SHOT": continue index = s["Shot Index"] start = s["Start Timestamp (milliseconds)"] / 1000 end = s["End Timestamp (milliseconds)"] / 1000 range_seg = range_toc.make_range( id=f"{range_id}/r{index}", label=f"Segment {index}", ) range_seg.items.append({ "id": f"{canvas_id}#t={start},{end}", "type": "Canvas" }) output_path = f"{self.input_dir}/manifest_segment.json" with open(output_path, "w") as f: f.write(manifest.json(indent=2)) return output_path 以下のようなマニフェストファイルが作成されます。 ...

iiif-prezi3を使って、動画にアノテーションを付与する

iiif-prezi3を使って、動画にアノテーションを付与する

概要 iiif-prezi3を使って、動画にアノテーションを付与する方法に関する備忘録です。 アノテーションの付与 Amazon Rekognitionのlabel detectionを用います。 https://docs.aws.amazon.com/rekognition/latest/dg/labels.html?pg=ln&sec=ft 以下などでサンプルコードが公開されています。 https://docs.aws.amazon.com/ja_jp/rekognition/latest/dg/labels-detecting-labels-video.html 特に、GetLabelDetectionにおける集計をSEGMENTSにすることで、StartTimestampMillisとEndTimestampMillisを得ることができます。 ただし、以下の点に注意が必要です。 SEGMENTS による集計の場合、境界ボックス付きの検出されたインスタンスに関する情報は返されません。 使用するデータ 『県政ニュース 第1巻』(県立長野図書館)を使用します。 https://www.ro-da.jp/shinshu-dcommons/library/02FT0102974177 マニフェストファイルへの反映 以下の記事などを参考に、マニフェストファイルが作成済みであるとします。 以下のようなスクリプトにより、マニフェストファイルにvttファイルを追加します。 from iiif_prezi3 import Manifest, AnnotationPage, Annotation, ResourceItem, config, HomepageItem, KeyValueString #| export class IiifClient: def load_manifest(self, manifest_path): with open(manifest_path, "r") as f: manifest_json = json.load(f) manifest = Manifest(**manifest_json) return manifest def add_label_segment(self, manifest_path): manifest = self.load_manifest(manifest_path) label_path = f"{self.input_dir}/output_label_seg.json" with open(label_path, "r") as f: label_seg = json.load(f) canvas = manifest.items[0] labels = label_seg["Labels"] anno_page_id = f"{canvas.id}/page1" anno_page = AnnotationPage(id=anno_page_id) canvas.annotations.append(anno_page) for i in range(len(labels)): label = labels[i] start = label["StartTimestamp"] / 1000 end = label["EndTimestamp"] / 1000 name = label["Label"]["Name"] anno_id = f"{anno_page_id}/a{i}" anno = Annotation( id=anno_id, motivation="tagging", target=canvas.id + "#t=" + str(start) + "," + str(end), body={ "type": "TextualBody", "value": name, "format": "text/plain", } ) anno_page.add_item( anno ) output_path = f"{self.input_dir}/manifest_label_seg.json" with open(output_path, "w") as f: f.write(manifest.json(indent=2)) return output_path 以下のようなマニフェストファイルが作成されます。 ...

[2024年版] AWSサーバーレスアプリケーションによるIIIF Image Serverの構築

[2024年版] AWSサーバーレスアプリケーションによるIIIF Image Serverの構築

概要 AWSサーバーレスアプリケーションによるIIIF Image Serverの構築に関する2024年度版の記事です。 背景 以下で、serverless-iiifというリポジトリが公開されています。本リポジトリを用いることにより、AWSのサービスを用いて、コスト効率が高く、無限にスケーラブルなIIIF Image Serverを構築することができると謳われています。 https://github.com/samvera/serverless-iiif 以下で、2022年時点の使い方を紹介しましたが、今日のサービスはより使いやすいものになっていました。 方法 いくつか構築方法がありますが、GUIを通じた構築方法として、以下を参考にします。基本的な構築については、以下のサイトの通り行います。ここでは、CloudFrontとRoute 53によるカスタムドメインの設定を含む手順について紹介します。 Lambdaの作成 https://samvera.github.io/serverless-iiif/docs/quick-start/deployment-sam まず、以下にアクセスします。 https://console.aws.amazon.com/lambda/home#/create/app?applicationId=arn:aws:serverlessrepo:us-east-1:625046682746:applications/serverless-iiif カスタムドメインによる配信にあたり、いくつかの設定を行います。 まず、ForceHostの項目に、設定したいカスタムドメイン名を入力します。 さらに、SourceBucketにバケット名を入力します。以下の例ではたまたまカスタムドメインと同じ名前の例ですが、任意のバケット名を入力します。 最後に、「このアプリがカスタム IAM ロールを作成することを承認します。」にチェックを入れて、「デプロイ」ボタンを押します。 その後に遷移する以下のような画面において、「デプロイ」タブを選択して、「CloudFormation スタック」のリンクをクリックします。 「出力」タブに遷移すると、v2やv3のエンドポイントが確認できます。 tiled TIFFsの作成 以下のページなどを参考に、tiled TIFFsファイルを作成します。 https://samvera.github.io/serverless-iiif/docs/source-images または、「『石見国絵図』,写,〔江戸中期〕. 国立国会図書館デジタルコレクション 」の画像をtile TIFFsに変換したファイルを以下から取得いただけます。サンプルデータとしてお使いください。 https://github.com/nakamura196/iiif-sampledata/raw/main/1286204.tif このファイルを先に指定したAmazon S3のバケットにアップロードすると、以下のようなURLでImage APIにアクセスすることができます。 https://istxbnjtm5x7qcpkwapsznyltm0sufnb.lambda-url.us-east-1.on.aws/iiif/3/1286204/info.json 注意点として、上記の結果得られるJSONファイルのidには、https://iiif.aws.ldas.jp/iiif/3/1286204という値が指定されています。 これは、先の設定で、ForceHostに指定した値が反映されています。 なお、画像の閲覧には、神崎正英氏が作成されているImage Annotatorが便利です。以下のように、uパラメータでURLを指定すると、画像を表示することができます。 https://www.kanzaki.com/works/2016/pub/image-annotator?u=https://istxbnjtm5x7qcpkwapsznyltm0sufnb.lambda-url.us-east-1.on.aws/iiif/3/1286204/info.json カスタムドメインの設定 最後にカスタムドメインの設定を行います。 まず、CloudFrontでディストリビューションを作成します。Origin domainには、先ほどアクセスしたURLのon.awsで終わるところまでを入力します。 そして、「代替ドメイン名 (CNAME)」の箇所において、設定したいドメイン名を入力します。合わせて、「Custom SSL certificate」も設定します。 上記でCloudFrontの設定は完了です。 最後に、Route 53でCloudFrontディストリビューションへの設定を行います。 結果、以下のURLからJSONファイルを取得することができます。 https://iiif.aws.ldas.jp/iiif/3/1286204/info.json まとめ 誤っている点もあるかもしれませんが、AWSサーバーレスアプリケーションによるIIIF Image Serverの構築にあたり、参考になりましたら幸いです。 ...

mdxのオブジェクトストレージを使用する(Cyberduckの利用)

mdxのオブジェクトストレージを使用する(Cyberduckの利用)

概要 mdxのオブジェクトストレージを使用する機会がありましたので、備忘録です。 https://mdx.jp/ 料金 2024年度の料金は以下のようになっています。 https://mdx.jp/guide/charge 1GBあたり、0.01ポイント(円)/日となっており、おおよそ1GBあたり、0.3円/月となっています。 申請方法 & s3cmdを用いた使い方 以下の公式チュートリアル動画が参考になりました。 https://www.youtube.com/watch?v=IN_4NS9hO2Y Cyberduckを使う 上記の動画ではコマンドラインツールによるファイル操作方法が紹介されています。 ここでは、Cyberduckを使用して、GUIを使ってファイル操作を行います。 AWS S3に対するCyberduckの操作方法を以下の記事で紹介しています。以下の方法を参考に、mdxのオブジェクトストレージに接続してみます。 接続設定 「新規接続」から接続設定を行います。 「Amazon S3」を選択して、サーバに「s3ds.mdx.jp」を入力します。 そして、発行された「アクセスキーID」および「シークレットアクセスキー」を入力します。 バケットの作成 右クリック > 「新規フォルダ」でバケットを作成できます。 ファイルのアップロード 以下のいらすとやさんの画像を使用します。 https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgNuMuIaXnIW5QJXkLiV1ojUeUiIwNQF1O0lp2LgG2LGJUbIU8j4bFAyLyKq3BiYp53p0Yc8AtMsEykJAQgEx4SJyFvKY4OyNeDBFopPb4lnV7_wtZNkr91qwj6-m-8s-sl1aadYMhrpuoI/s800/baby_asia_boy.png 「satoru196」フォルダにドラッグ&ドロップでアップロードすることができます。 上述した公式チュートリアルでも言及されていますが、このままでは以下のURLにアクセスしても、表示ができません。 https://s3ds.mdx.jp/satoru196/baby_asia_boy.png 以下のようなエラーコードが表示されます。 <Error> <script/> <Code>AccessDenied</Code> <Message>Access Denied</Message> <RequestId>...</RequestId> <HostId>00000000000000000</HostId> </Error> ACLの変更 ファイルを右クリックして、「情報」をクリックします。 以下のように、Everyoneを選択して、 READ権限を付与します。 この結果、以下のURLから画像を閲覧することができます。 https://s3ds.mdx.jp/satoru196/baby_asia_boy.png まとめ mdxのオブジェクトストレージを活用することで、様々な用途がありますが、例えばメディアを安価に公開することができそうです。特に、デジタルアーカイブにおけるメディアの公開元として、有力なインフラになり得るかと思います。 mdxのs3互換のオブジェクトストレージの利用にあたり、参考になりましたら幸いです。

Amazon S3とRoute 53を使ってリダイレクトする

Amazon S3とRoute 53を使ってリダイレクトする

概要 あるURLから他のURLにリダイレクトさせる必要があり、Amazon S3とRoute 53を使用して実現することができたので、備忘録です。 方法 この方法では、S3バケットを使ってリダイレクトを行い、DNS設定にはRoute 53を使用します。以下にその手順を説明します。 ステップ1: Amazon S3バケットの設定 Amazon S3で新しいバケットを作成します。バケット名はリダイレクトさせたいドメイン名と一致させます(例:example.com)。 バケットのプロパティで「静的ウェブサイトホスティング」を選択します。 「静的ウェブサイトホスティング」のオプションで、「リダイレクト要求」を選び、リダイレクト先のURL(http://example.net など)を入力します。 ステップ2: Route 53でのDNS設定 Route 53で、リダイレクトするドメイン名のホストゾーンを開きます。 新しいレコードセットを作成します。レコードのタイプは A を選択します。 「エイリアス」を「はい」に設定します。 エイリアスターゲットとして、ステップ1で設定したS3バケットの静的ウェブサイトホスティングのエンドポイントを選択します(例:example.com.s3-website-us-east-1.amazonaws.com)。 これで、指定したドメインにアクセスがあった場合、設定したURLにリダイレクトされるようになります。この方法は、簡単でありながら効果的にドメインから別のURLへのリダイレクトを実現することができます。 まとめ 参考になりましたら幸いです。

StrapiでCSPのエラーが発生した際の対処法

StrapiでCSPのエラーが発生した際の対処法

概要 Strapiと以下のプラグインを使って、メディアをS3に格納する構成としました。 https://www.npmjs.com/package/@liashchynskyi/strapi-provider-upload-s3-cloudfront その際、以下のエラーが発生し、画像が表示されませんでした。 Refused to load the image 'https://xxx/uploads/yyy.jpg' because it violates the following Content Security Policy directive: "img-src 'self' data: blob: dl.airtable.com". この課題に対して、以下の記事で述べられている通り、./config/middleware.jsを修正することで、この問題を解決することができました。 https://zenn.dev/studiobros/articles/04400f413eb2aa ACLについても 同様に、S3にメディアをアップロードできない状態にも遭遇しましたが、上記の記事にある通り、S3のACLを有効にし、さらに適切なブロックパブリックアクセス (バケット設定)を設定することで、無事にアップロードできるようになりました。 まとめ StrapiとS3を組み合わせたヘッドレスCMSの構築にあたり、参考になりましたら幸いです。

AWS CLIを使用したS3バケットの一括削除

AWS CLIを使用したS3バケットの一括削除

AWS CLIを使用してS3バケットの一覧を取得し、特定のパターンに基づいてバケットを削除するには、以下の手順を実行できます。ここでは、wbyという文字列で始まるバケットを削除する方法について説明します。 必要なもの AWS CLIがインストールされていること。 適切なAWSの認証情報とアクセス権限が設定されていること。 ステップ 1: バケットの一覧を取得 まず、インストールされているAWS CLIを使用して、すべてのS3バケットの一覧を取得します。 aws s3 ls ステップ 2: 条件に一致するバケットの削除 wbyで始まるバケットを削除するには、シェルスクリプトを利用して条件に一致するバケットをフィルタリングし、それらを削除します。 以下のスクリプトは、wbyで始まるバケット名を検索し、各バケットを削除します。注意:このスクリプトはバケットとその中のすべてのオブジェクトを削除します。実行前にデータのバックアップを確認してください。 aws s3 ls | awk '{print $3}' | grep '^wby' | while read bucket do echo "Deleting bucket $bucket..." aws s3 rb s3://$bucket --force done このスクリプトは次のことを行います: aws s3 lsでバケット一覧を取得。 awk '{print $3}'でバケット名のみを抽出。 grep '^wby'でwbyで始まるバケット名をフィルタリング。 while read bucketループで各バケットを削除。 注意 バケットを削除する前に、必要なデータがバックアップされていることを確認してください。 バケットが空でない場合、aws s3 rb --forceオプションを使用してバケットとその中のすべてのオブジェクトを削除します。 実行する前に、削除されるバケット名を確認するために、実際に削除するコマンドを実行する前にechoステートメントを挟むことをお勧めします。

ArchivematicaでAmazon S3を処理対象およびAIPの保存先に設定する

ArchivematicaでAmazon S3を処理対象およびAIPの保存先に設定する

概要 Archivematicaにおいて、Amazon S3上のファイルやフォルダを処理対象として、さらに処理結果であるAIPをS3に保存する方法に関する備忘録です。 S3をストレージとして利用することにより、他のシステムとの連携の容易化や、AIPの長期保存に関する選択肢が増えると考えられます。 ウェルカムコレクションの以下の記事が参考になりました。 https://docs.wellcomecollection.org/archivematica/administering-archivematica/bootstrapping Amazon S3の設定 バケットを作成します。今回、us-east-1リージョンに、archivematica.aws.ldas.jpというバケットを作成しました。 そして処理対象のファイルなどを格納する「transfer_source」、処理結果であるAIPを格納する「aip_storage」というフォルダを作成しておきます。これらの名前や階層は任意で、後述の過程でどのフォルダを使用するか設定できます。 Archivematica Storage Serviceの設定 Dockerを使ってArchivematicaをインストールした場合、以下のようなURLでArchivematica Storage Serviceにアクセスできます。 http://127.0.0.1:62081/ ログイン後、以下にアクセスします。「Create new space」リンクをクリックします。 /spaces/ 「Create Space」の画面で、以下のように入力します。「Access protocol」にS3を選択し、Access Keyなどを入力します。 Staging pathについてはよくわからず、以下の記事の値を入力します。 https://docs.wellcomecollection.org/archivematica/administering-archivematica/bootstrapping#step_7 Spaceを作成後、「Create Location here」を押して、ロケーションを作成します。2つリンクがありますが、どちらも同じでした。 ここで、2つのロケーションを作成します。一つは、以下のような、Purposeを「Transfer Source」とするロケーションです。 Relative Pathについては、「Browse」ボタンから、先に作成したフォルダから選択します。 また上記ではPipelineがひとつですが、複数のPipelineを作成している場合には、関連づけるものを選択することになると思います。 もう一つは、以下のような、Purposeを「AIP Storage」とするロケーションです。 それぞれの画面で、「Set as global default location for its purpose:」という項目がありますが、これをチェックしておくと、後述するデフォルト設定などが不要になります。 確認 ここまでの設定により、/spaces/にアクセスすると、デフォルトのAccess Protocolが「Local Filesystem」のスペースに加えて、Access Protocolが「S3」のスペースが追加されていることが確認できます。 さらに、/locations/にアクセスすると、追加した2つのロケーションが追加されていることが確認できます。 Archivematica Dashboardの設定 Dockerを使ってArchivematicaをインストールした場合、以下のようなURLでArchivematica Dashboardにアクセスできます。 http://127.0.0.1:62080/ AIPの格納先の設定 そして以下にアクセスして、例えばプロセスautomatedを編集します。 /administration/processing/ ...

Docker版Cantaloupeを使用して、S3バケットにアクセスしSSL通信を行う方法

Docker版Cantaloupeを使用して、S3バケットにアクセスしSSL通信を行う方法

概要 Docker版のCantaloupeの使い方を以下で紹介しました。 このDocker版Cantaloupeを(大規模ではない)production環境で使用するには、Amazon S3との接続や、SSL対応が求められます。その方法を一例を紹介します。 Amazon S3との接続 公式では以下で紹介されています。 https://cantaloupe-project.github.io/manual/5.0/sources.html#S3Source 日本語の記事として以下があります。 また、今回扱うDocker版では、以下に記載がありました。 https://github.com/Islandora-Devops/isle-buildkit/blob/main/cantaloupe/README.md#settings そこで、S3と最低限の接続を行うためのリポジトリを作成しました。 https://github.com/nakamura196/docker_cantaloupe_s3 .env.exampleを.envにリネームまたはコピーして、必要な値を入力します。 SSL対応 以下の記事を参考にしました。EC2上にDockerをインストールし、nginx-proxyとnginx-proxy-lets-encryptを利用してSSL化を行いました。 https://qiita.com/atsuya/items/7cb6e0ccee63d751d41f version: '3' # proxy services: nginx-proxy: image: jwilder/nginx-proxy container_name: nginx-proxy ports: - "80:80" - "443:443" volumes: - html:/usr/share/nginx/html - dhparam:/etc/nginx/dhparam - vhost:/etc/nginx/vhost.d - certs:/etc/nginx/certs:ro - /var/run/docker.sock:/tmp/docker.sock:ro - /srv/docker/nginx-proxy-with-encrypt/log:/var/log/nginx labels: - "com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy" restart: always letsencrypt: image: jrcs/letsencrypt-nginx-proxy-companion container_name: nginx-proxy-lets-encrypt depends_on: - "nginx-proxy" volumes: - certs:/etc/nginx/certs:rw - vhost:/etc/nginx/vhost.d - html:/usr/share/nginx/html - /var/run/docker.sock:/var/run/docker.sock:ro volumes: certs: html: vhost: dhparam: networks: default: external: name: common_link services: cantaloupe: image: islandora/cantaloupe:2.0.10 environment: CANTALOUPE_ENDPOINT_ADMIN_ENABLED: false CANTALOUPE_ENDPOINT_ADMIN_SECRET: my_admin_pass CANTALOUPE_SOURCE_STATIC: S3Source CANTALOUPE_S3SOURCE_ACCESS_KEY_ID: ${CANTALOUPE_S3SOURCE_ACCESS_KEY_ID} CANTALOUPE_S3SOURCE_SECRET_KEY: ${CANTALOUPE_S3SOURCE_SECRET_KEY} CANTALOUPE_S3SOURCE_REGION: ${CANTALOUPE_S3SOURCE_REGION} CANTALOUPE_S3SOURCE_BASICLOOKUPSTRATEGY_BUCKET_NAME: ${CANTALOUPE_S3SOURCE_BASICLOOKUPSTRATEGY_BUCKET_NAME} CANTALOUPE_S3SOURCE_LOOKUP_STRATEGY: BasicLookupStrategy # Or another strategy if needed VIRTUAL_HOST: <カスタムドメイン> LETSENCRYPT_HOST: <カスタムドメイン> LETSENCRYPT_EMAIL: <メールアドレス> restart: always networks: default: external: name: common_link まとめ IIIF画像サーバの小中規模の利用にあたっては、上記のような形が比較的容易な導入方法の一つに当たるかと思います。 ...

Amazon Lightsail上に立てたOmeka SからAmazon SESでメールを送信する

Amazon Lightsail上に立てたOmeka SからAmazon SESでメールを送信する

概要 Amazon Lightsail上に立てたOmeka Sからメールを送るには、メールの送信設定が必要なようです。今回は、Amazon SESを使用する方法を紹介します。 https://aws.amazon.com/jp/ses/ 以下のフォーラムでのやりとりが参考になりました。 https://forum.omeka.org/t/configuring-sendmail-or-smtp-for-omeka-s-on-amazon-lightsail/19335/1 Amazon SESの設定 以下のサイトなどを参考にして、Amazon SESの設定を行います。 https://qiita.com/Shun_konno/items/f51ae599b68e0d2d36ea Omeka Sの設定 Omeka S の local.config.php ファイルを以下のように編集します。 <?php return [ 'logger' => [ // ログ設定(必要に応じて) ], 'mail' => [ 'transport' => [ 'type' => 'smtp', // SMTP を使用 'options' => [ 'name' => 'ses-smtp-user', // 任意の名前 'host' => 'email-smtp.us-east-1.amazonaws.com', // SES SMTP サーバーエンドポイント 'port' => 587, // SES がサポートするポート(例: 587) 'connection_class' => 'plain', // 認証タイプ 'connection_config' => [ 'username' => 'your-ses-smtp-username', // SES SMTP ユーザー名 'password' => 'your-ses-smtp-password', // SES SMTP パスワード 'ssl' => 'tls', // SSL タイプ('tls' 推奨) 'use_complete_quit' => true, ], ], ], ], // その他の設定... ]; host には、使用している AWS リージョンに応じた Amazon SES SMTP サーバーのエンドポイントを指定してください。例では us-east-1 リージョンのエンドポイントを使用していますが、必要に応じて変更してください。 username と password は、Amazon SES で生成した SMTP クレデンシャルを使用してください。 まとめ Amazon Lightsailを用いたOmeka Sの利用にあたり、参考になりましたら幸いです。 ...

Amazon SNSを用いたEC2上のVirtuosoの再起動

Amazon SNSを用いたEC2上のVirtuosoの再起動

概要 以下の記事で、ヘルスチェックを行う方法について記述しました。 また、Virtuosoが停止した際の再起動のためのコマンドを以下に記述しました。 今回は、Amazon SNSを用いた通知に合わせて、Virtuosoを再起動してみます。 方法 EC2インスタンスにsudo rm -rf /usr/local/var/lib/virtuoso/db/virtuoso.lck && ...のようなコマンドを送信するには、SSM(AWS Systems Manager)に関する設定が必要でした。 IAMロールとポリシー IAMロールを新規に作成して、AmazonSSMFullAccessというポリシーを許可しました。はじめ、AmazonSSMManagedInstanceCoreというポリシーを許可していましたが、後述するlambda実行時に以下のようなエラーが発生して、うまく動作させることができませんでした。 An error occurred (InvalidInstanceId) when calling the SendCommand operation: Instances [[i-xxxxxx]] not in a valid state for account xxxxxx EC2インスタンスの「IAMロールを変更」から、作成したIAMロールを選択して更新しました。 AWS SAM: lamda関数の作成 AWS SAMを用いました。以下でのプロジェクトを作成します。 sam init hello_world/app.pyを以下のように作成しました。instance_idの部分には、要修正です。 import boto3 import time def lambda_handler(event, context): # EC2クライアントの初期化 ec2 = boto3.client('ec2') # 特定のEC2インスタンスIDを指定 instance_id = 'i-xxxxxxxx' # EC2インスタンスのステータスチェック response = ec2.describe_instance_status(InstanceIds=[instance_id]) if len(response['InstanceStatuses']) == 0: print(f"インスタンス {instance_id} は停止中です。") return # Define the command to be executed on the instance (e.g., restart software) command = 'sudo rm -rf /usr/local/var/lib/virtuoso/db/virtuoso.lck && sudo /usr/local/bin/virtuoso-t +configfile /usr/local/var/lib/virtuoso/db/virtuoso.ini' # SSMを通じてEC2インスタンスにコマンドを送信 ssm_client = boto3.client('ssm') response = ssm_client.send_command( InstanceIds=[instance_id], DocumentName='AWS-RunShellScript', Parameters={'commands': [command]} ) time.sleep(1.0) command_id = response['Command']['CommandId'] output = ssm_client.get_command_invocation( CommandId=command_id, InstanceId=instance_id, ) print("コマンドを実行しました。") # Extract only the necessary information from the output simplified_response = { "Output": output['StandardOutputContent'], "Error": output['StandardErrorContent'], } return simplified_response また、hello_word/requirements.txtにboto3を追記しました。 ...

samでError: Running AWS SAM projects locally requires Docker...への対応

samでError: Running AWS SAM projects locally requires Docker...への対応

概要 AWS SAMを使ってsam local invokeを試した際、以下のメッセージが表示されました。 Error: Running AWS SAM projects locally requires Docker. Have you got it installed and running? 環境はMacで、Dockerも動作していました。 対処法 以下を実行することで、解決しました。 sudo ln -s ~/.docker/run/docker.sock /var/run/docker.sock 以下を参考にしました。 https://github.com/lando/lando/issues/3533 まとめ 同様の事象でお困りの方の参考になりましたら幸いです。

Cantaloupe: Amazon S3に格納した画像を配信する

Cantaloupe: Amazon S3に格納した画像を配信する

概要 IIIFイメージサーバの一つであるCantaloupe Image Serverについて、Amazon S3に格納した画像を配信する方法の備忘録です。 なお、Amazon S3に格納した画像を配信する別の方法として、以下の記事で紹介した方法もありますので、参考になりましたら幸いです。(記事執筆時点からツールが更新されているようで、記事通りに進められないかもしれません。) 設定 以下に公式マニュアルが公開されています。 https://cantaloupe-project.github.io/manual/5.0/sources.html#S3Source 以下のファイルを編集します。 /cantaloupe-5.0.5/cantaloupe.properties まず、source.staticをS3Sourceに変更しました。 ########################################################################### # SOURCES ########################################################################### # Uses one source for all requests. Available values are `FilesystemSource`, # `HttpSource`, `JdbcSource`, `S3Source`, and `AzureStorageSource`. # source.static = FilesystemSource source.static = S3Source 次に、S3Source.access_key_id、S3Source.secret_key、S3Source.BasicLookupStrategy.bucket.nameを設定します。 #---------------------------------------- # S3Source #---------------------------------------- # !! Endpoint URI. Only needed for non-AWS endpoints. S3Source.endpoint = # !! AWS region. Only needed for AWS endpoints. S3Source.region = # !! Credentials for your AWS account. # See: http://aws.amazon.com/security-credentials # Note that this info can be obtained from elsewhere rather than setting # it here; see the user manual. S3Source.access_key_id = <アクセスキー> S3Source.secret_key = <シークレットキー> # How to look up objects. Allowed values are `BasicLookupStrategy` and # `ScriptLookupStrategy`. ScriptLookupStrategy uses a delegate method for # dynamic lookups; see the user manual. S3Source.lookup_strategy = BasicLookupStrategy # !! Name of the bucket containing images to be served. S3Source.BasicLookupStrategy.bucket.name = <バケット名> これでAmazon S3に格納した画像が参照されるようになりました。 ...

Amazon OpenSearch ServiceでDisable autotuneを行う

Amazon OpenSearch ServiceでDisable autotuneを行う

Amazon OpenSearch Serviceの開発用のドメインにおいて、インスタンスタイプをt3.small.searchからt3.medium.searchに変更しようとしたところ、以下のメッセージが表示されました。 Autotune is not supported in t2/t3 instance types. Disable autotune or change your instance type. UI上ではAutotuneに関する項目を見つけることができずに困っていたところ、以下のページにCLIを使う方法が記載されていました。 https://docs.aws.amazon.com/opensearch-service/latest/developerguide/auto-tune.html#auto-tune-enable そこで、以下を実行しました。 aws opensearch update-domain-config \ --domain-name my-domain \ --auto-tune-options DesiredState=DISABLED その上で、再度インスタンスタイプを変更したところ、無事に変更することができました。 Autotuneの機能を無効化する、または使用しないことのデメリットなどを十分に把握できていませんが、同様のことでお困りの方の参考になりましたら幸いです。

EC2に立てたArchivematicaをHTTPS対応する

EC2に立てたArchivematicaをHTTPS対応する

はじめに 以下の記事で、EC2にArchivematicaを立てる方法を記載しました。 今回は、独自ドメインの設定とHTTPS対応を行います。 独自ドメインの設定 今回、matica.aws.ldas.jpとstorage.aws.ldas.jpいうドメインを<IPアドレス>に割り当てます。Route 53を使用します。 SSL証明書の取得 sudo su yum install epel-release yum install certbot ertbot certonly --webroot -w /usr/share/nginx/html -d matica.aws.ldas.jp -d storage.aws.ldas.jp Webサーバの設定: Nginxのインストール vi /etc/nginx/conf.d/archivematica-and-storage.conf 設定 server { listen 80; server_name matica.aws.ldas.jp; rewrite ^(.*)$ https://$host$1 permanent; } server { listen 80; server_name storage.aws.ldas.jp; rewrite ^(.*)$ https://$host$1 permanent; } server { listen 443 ssl; server_name matica.aws.ldas.jp; ssl_certificate /etc/letsencrypt/live/matica.aws.ldas.jp/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/matica.aws.ldas.jp/privkey.pem; location / { proxy_pass http://localhost:81; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } server { listen 443 ssl; server_name storage.aws.ldas.jp; ssl_certificate /etc/letsencrypt/live/storage.aws.ldas.jp/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/storage.aws.ldas.jp/privkey.pem; location / { proxy_pass http://localhost:8001; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } 結果、以下のURLにアクセスできるようになりました。 ...

IIIFイメージサーバの一つであるCantaloupeをEC2で起動する

IIIFイメージサーバの一つであるCantaloupeをEC2で起動する

概要 IIIFイメージサーバの一つであるCantaloupeをEC2で起動する方法の備忘録です。 https://cantaloupe-project.github.io/ 加えて、画像のダウンロードサイズに制限を加えるDelegate Methodsの一例についても紹介します。具体的には、フルサイズの画像を/full/full/で取得しようとした際、エラーが出てしまうケースへの対応を行います。 https://cantaloupe-project.github.io/manual/5.0/access-control.html Cantaloupeのセットアップ EC2インスタンスの作成 プラットフォームをUbuntu、インスタンスタイプをt2.medium、ストレージを8GB、に設定したEC2インスタンスを作成しました。 結果、以下の「パブリック IPv4 アドレス」を持つEC2インスタンスが作成されました。 54.172.71.20 ssh 起動したEC2インスタンスにsshで接続します。接続後、以下のコマンドにより、rootユーザのパスワードを設定します。 sudo su passwd javaのインストール 以下のコマンドなどにより、javaをインストールします。 apt-get update apt install default-jre cantaloupeのダウンロード 以下のコマンドなどにより、cantaloupeをダウンロードします。 apt install unzip wget https://github.com/cantaloupe-project/cantaloupe/releases/download/v5.0.5/cantaloupe-5.0.5.zip unzip cantaloupe-5.0.5.zip 設定 以下のコマンドなどにより、設定ファイル「cantaloupe.properties」を編集します。 cd cantaloupe-5.0.5 # 設定例ファイルから設定ファイルをコピー cp cantaloupe.properties.sample cantaloupe.properties vi cantaloupe.propertiesなどのコマンドにより、画像を格納するフォルダを指定します。 cantaloupe.properties FilesystemSource.BasicLookupStrategy.path_prefix = /home/ubuntu/images/ cantaloupeの起動 java -Dcantaloupe.config=cantaloupe.properties -Xmx2g -jar cantaloupe-5.0.5.jar 以下のようなURLでcantaloupeが起動します。 http://54.172.71.20:8182/ 画像の配置 サーバ上での作業 ubuntuユーザで/home/ubuntu/imagesに画像を格納するフォルダを作成します。 su ubuntu mkdir /home/ubuntu/images ローカルでの作業 以下のノートブックなどを使って、pyramid tiled tifをローカルにダウンロードします。 https://zenn.dev/nakamura196/articles/ef6b0937e4e887 ...

macOS版のCyberduckを使って、AWS S3の特定のバケットにアクセスする

macOS版のCyberduckを使って、AWS S3の特定のバケットにアクセスする

以下の記事を参考に、Cyberduckを使って、AWS S3の特定のバケットにアクセスする方法を試しました。 https://dev.classmethod.jp/articles/specify_s3_folder_iam_cyberduck/ しかしmacOS版のCyberduckを開き、画面上部の「新規接続」ボタンを押したところ、バケットの情報などを入力するフォームが表示されませんでした。 そこで調べてみたところ、以下のIssueが見つかりました。 https://github.com/iterate-ch/cyberduck/issues/11154 以下のように、ブックマークを開くように、とのことでした。 Please refer to Access third party buckets. To set a default path, create a new bookmark instead of choosing Open Connectoin. そこで、以下のように、画面左下の「+」ボタンをクリックしたところ、 以下のように、詳細設定のフォームも表示され、パス(バケット名)を指定できるようになりました。 同様のことでお困りの方の参考になりましたら幸いです。

Amazon EC2に立てたVirtuosoのヘルスチェックを行う

Amazon EC2に立てたVirtuosoのヘルスチェックを行う

概要 Amazon EC2に立てたVirtuosoのヘルスチェックを行う機会がありましたので、その備忘録です。 具体的には、何らかの不具合で、Virtuoso(https://xxx.zzz/sparql など)がエラーを返すようになってしまった際、その内容をメールで通知します。 方法 以下の記事で、Amazon EC2にVirtuoso RDFストアを構築する方法を紹介しています。 上記では、ELBを使用しています。上記の記事から1点だけ変更を行う必要があります。Health check pathを/に設定していますが、この部分をSPARQLエンドポイントへのパス(例えば/sparql)に変更します。 その後、以下の記事を参考に、CloudWatchやAmazon SNSの設定を行いました。 https://dev.classmethod.jp/articles/elb-healthcheck-monitoring-by-cloudwatch-alarm/ 結果 以下のようにモニタリングを行うことができるようになりました。 またアラート発生時には、以下のようなメールが届くようになりました。 You are receiving this email because your Amazon CloudWatch Alarm "virtuoso-unhealthyhostcount-alarm" in the US East (N. Virginia) region has entered the ALARM state, because "Threshold Crossed: no datapoints were received for 5 periods and 5 missing datapoints were treated as [Breaching]." at "Friday 14 July, 2023 08:05:30 UTC". View this alarm in the AWS Management Console: https://us-east-1.console.aws.amazon.com/cloudwatch/deeplink.js?region=us-east-1#alarmsV2:alarm/virtuoso-unhealthyhostcount-alarm Alarm Details: - Name: virtuoso-unhealthyhostcount-alarm - State Change: OK -> ALARM - Reason for State Change: Threshold Crossed: no datapoints were received for 5 periods and 5 missing datapoints were treated as [Breaching]. - Timestamp: Friday 14 July, 2023 08:05:30 UTC - AWS Account: xxxxxxxxxxxxxx - Alarm Arn: arn:aws:cloudwatch:us-east-1:xxxxxxxxxxxxxx:alarm:virtuoso-unhealthyhostcount-alarm Threshold: - The alarm is in the ALARM state when the metric is GreaterThanOrEqualToThreshold 1.0 for at least 5 of the last 5 period(s) of 60 seconds. Monitored Metric: - MetricNamespace: AWS/ApplicationELB - MetricName: UnHealthyHostCount - Dimensions: [TargetGroup = targetgroup/virtuoso] [AvailabilityZone = us-east-1a] [LoadBalancer = app/virtuoso/yyyyyyyyyyyyyyy] - Period: 60 seconds - Statistic: Minimum - Unit: not specified - TreatMissingData: breaching State Change Actions: - OK: - ALARM: [arn:aws:sns:us-east-1:xxxxxxxxxxxxxx:Default_CloudWatch_Alarms_Topic] - INSUFFICIENT_DATA: まとめ 同様の環境でVirtuosoを運用されている際の参考になりましたら幸いです。 ...