1 Minute Tips

投稿者: sumito.tsukada

  • AWS SAM CLIでPython 3.11のビルドエラーを解決する方法

    AWS SAM CLIでPython 3.11のビルドエラーを解決する方法

    はじめに

    AWS SAM (Serverless Application Model) は、サーバーレスアプリケーションの開発を容易にするフレームワークです。しかし、新しいランタイムバージョンがリリースされると、開発者はしばしば互換性の問題に直面します。この記事では、AWS SAM CLIでPython 3.11ランタイムを使用する際に発生する一般的なビルドエラーについて説明し、その解決方法を提供します。

    エラーの概要

    問題: AWS SAM CLIでPython 3.11ランタイムを使用してビルドを試みると、次のようなエラーメッセージが表示されます。

    Build Failed Error: 'python3.11' runtime is not supported

    このエラーは、使用中のAWS SAM CLIのバージョンがPython 3.11をサポートしていないことを示しています。

    解決策

    ステップ 1: AWS SAM CLIを最新バージョンにアップグレードします。

    python3.11 -m pip install --upgrade aws-sam-cli

    このコマンドにより、AWS SAM CLIが最新バージョンに更新され、Python 3.11ランタイムのサポートが含まれます。

    ステップ 2: 再度ビルドを実行します。

    sam build

    成功すると、以下のようなメッセージが表示されます。

    Build Succeeded

    なぜこの解決策が効果的なのか

    AWS SAM CLIは定期的に更新され、新しい機能やランタイムのサポートが追加されます。Python 3.11のような新しいランタイムがリリースされた場合、AWS SAM CLIもそれをサポートするために更新が必要になります。したがって、最新バージョンへのアップグレードは、この種の互換性問題を解決する最も直接的な方法です。

    結論

    AWS SAM CLIでPython 3.11ランタイムのビルドエラーに直面した場合、最も簡単な解決策はAWS SAM CLIを最新バージョンにアップグレードすることです。この記事が、同様の問題に直面している開発者の助けになることを願っています。

  • Dockerの未タグ付けイメージを一括削除：ストレージの最適化方法

    Dockerの未タグ付けイメージを一括削除：ストレージの最適化方法

    はじめに

    Dockerを使用していると、ビルドやテストの過程で多数の未使用、未タグ付けのイメージが生成されることがあります。これらは、<none>として表示され、時間とともにストレージを圧迫してしまいます。特に、頻繁にイメージをビルドする開発者や、ストレージ容量に制限がある環境で作業している人にとって、この問題は大きな悩みの一つです。

    未タグ付けイメージとは？

    Dockerの未タグ付けイメージは、以前のビルドからの残骸や、新しいイメージをビルドする際に古いイメージがタグなしで残されることが原因で生成されます。これらは<none>として表示され、通常は手動での削除が必要です。

    未タグ付けイメージの一括削除方法

    以下のコマンドを使用して、未タグ付けのイメージを一括で削除することができます。

    docker rmi $(docker images -f "dangling=true" -q)

    このコマンドは、未タグ付けのイメージIDをリストし、それをdocker rmiコマンドに渡して削除します。

    注意点

    未タグ付けのイメージを削除する前に、使用中のコンテナが存在しないか確認してください。使用中のコンテナがある場合、関連するコンテナを先に停止または削除する必要があります。

    まとめ

    Dockerの未タグ付けイメージはストレージの無駄な使用を引き起こす可能性があります。定期的にこれらのイメージをクリーンアップすることで、効率的なストレージ管理を実現できます。上記のコマンドを利用して、容易にストレージの最適化を行うことができます。

  • Dockerビルドエラーの原因と対策：apt-get updateエラーの解消方法

    Dockerビルドエラーの原因と対策：apt-get updateエラーの解消方法

    はじめに

    Dockerを利用したシステム開発・運用において、ビルドプロセス中に突然のエラーが発生するケースは少なくありません。特に、apt-get update や apt-get install コマンド実行時に見られるエラーは、ビルドの中断やデプロイの遅延につながり、業務に大きな影響を及ぼす可能性があります。この記事では、DebianベースのDockerイメージをビルド中に発生したリポジトリ署名エラーの原因と、それに対処するための具体的な手法について解説します。

    問題の発生：Dockerビルド中のエラー内容

    Dockerイメージをビルドする際、以下のエラーメッセージが表示され、プロセスが中断されました。

    #0 1.518 Err:1 http://deb.debian.org/debian bullseye InRelease
#0 1.518 At least one invalid signature was encountered.
...
#0 2.793 E: The repository 'http://deb.debian.org/debian bullseye-updates InRelease' is not signed.
ERROR: failed to solve: process "/bin/sh -c apt-get update && apt-get install -y openssh-client git libzip-dev && rm -rf /var/lib/apt/lists/*" did not complete successfully: exit code: 100

    このエラーにより、Dockerビルドプロセスが正常に完了せず、継続的な開発やデプロイに支障をきたしました。業務における生産性や信頼性確保の観点からも、迅速な原因特定と解決が求められます。

    原因の特定：リポジトリ署名エラーではなくストレージ不足

    初見では、リポジトリの署名エラーが原因と推測されるケースが多いですが、今回のエラーは異なりました。調査の結果、Dockerビルド時に一時ファイルが大量に生成され、サーバー上のストレージ容量が不足したことが根本原因でした。

    • 一時ファイルの蓄積:
      apt-get install コマンドは、パッケージのダウンロードおよびインストールの過程で一時ファイルを作成します。これが限られたストレージ領域を圧迫することで、結果的にビルドエラーを引き起こしました。
    • Dockerのキャッシュ管理:
      Dockerはビルドプロセス中にキャッシュや未使用リソースを保持するため、定期的なクリーンアップが不可欠です。ストレージ不足は、こうしたキャッシュが蓄積された結果とも言えます。

    対処法：ストレージ容量の確保とクリーンアップ手法

    問題解決には、まず十分なストレージ容量の確保が必要です。そこで、以下のコマンドを実行し、不要なDockerリソースを一掃することで、空き容量を確保しました。

    docker system prune --volumes

    このコマンドは、未使用のコンテナ、ネットワーク、イメージ、およびボリュームを削除し、システム全体のリソース管理を最適化します。特に、継続的にDockerを利用する環境では、定期的なクリーンアップを自動化する仕組みを導入することが推奨されます。

    結果：エラー解消とビルドプロセスの正常化

    上記の対処法を実施した後、再度Dockerビルドを試みたところ、エラーは解消され、プロセスが正常に完了しました。これにより、開発スケジュールへの影響を最小限に抑えることができ、運用環境の信頼性も向上しました。

    まとめ：Docker環境の健全な運用のために

    今回の事例は、Dockerビルド時のエラーメッセージが必ずしも原因を直接示していないことを示しています。エラーメッセージの裏に潜む要因（今回の場合はストレージ不足）を見極めるためには、以下のポイントが重要です。

    • 定期的なリソース管理:
      Dockerの未使用リソースやキャッシュの定期的なクリーンアップを実施し、ストレージ容量を最適化する。
    • 多角的なトラブルシューティング:
      エラー発生時には、単一の原因にとらわれず、システム全体のリソース状況や設定を総合的に確認する。
    • 自動化ツールの活用:
      Docker環境では、自動化ツールや監視システムを導入し、リソース使用状況をリアルタイムで把握することが効果的です。

    これらの対策により、Docker環境でのビルドエラーを未然に防ぎ、業務の効率化と信頼性向上を実現できます。Dockerのトラブルシューティングに関する知識とスキルは、今後の開発・運用において不可欠な要素となるでしょう。

  • GitLab CIを利用してSSHキーを安全に管理する

    GitLab CIを利用してSSHキーを安全に管理する

    はじめに

    プロジェクトではしばしばSSHキーを使用してリモートサーバーにアクセスする必要があります。しかし、これらのキーを安全に管理することは非常に重要です。GitLab CIは、プロジェクトの秘密を安全に管理するための環境変数機能を提供しています。この記事では、GitLabの環境変数にSSHキーを登録し、GitLab CIでキーを成形し、その有効性を確認する方法を示します。

    手順

    1. SSHキーの登録: 最初に、GitLabのプロジェクト設定ページにアクセスし、左側のメニューで「CI/CD」を選択します。次に、「Variables」セクションに移動し、「Add Variable」をクリックします。キーとしてDEPLOY_USER_KEYを使用し、値としてSSHプライベートキーをペーストします。

      例:

      -----BEGIN RSA PRIVATE KEY-----
      MIIEpAIBAAKCAQEA3...（中略）...3n59+PBlU9Kl
      -----END RSA PRIVATE KEY-----

    2. キーの成形: 次に、.gitlab-ci.ymlファイルを作成し、以下の内容を追加します。この設定は、登録したSSHキーを成形し、id_rsaファイルに保存します。

      stages:
      - prepare

      create_ssh_key:
      stage: prepare
      script:
      - |
      echo "$DEPLOY_USER_KEY" | python3 -c "
      import sys
      key = sys.stdin.read().strip()
      header = '-----BEGIN RSA PRIVATE KEY-----'
      footer = '-----END RSA PRIVATE KEY-----'
      key_body = key.replace(header, '').replace(footer, '').strip()
      key_body = key_body.replace(' ', '\n')
      print(f'{header}\n{key_body}\n{footer}')" > id_rsa
       only:
      - master

    3. キーの確認: 最後に、キーの有効性を確認するためにssh-keygenコマンドを使用します。

      stages:
      - prepare
      - verify

      create_ssh_key:
      stage: prepare
      script:
      #...（前のステップと同じ）...

      verify_ssh_key:
      stage: verify
      script:
      - ssh-keygen -l -f id_rsa
      only:
      - master

    結論

    この設定を使用することで、GitLab CIを利用してSSHキーを安全に管理し、その有効性を確認することができます。これにより、プロジェクトのセキュリティを維持しながらリモートサーバーへのアクセスを簡単に管理できます。

  • Postfix 3.5.9-r0 と Alpine Linux の「hash」辞書タイプサポートの変更に対応する方法

    Postfix 3.5.9-r0 と Alpine Linux の「hash」辞書タイプサポートの変更に対応する方法

    Postfix は、多くのシステム管理者にとって信頼性の高いメールサーバーとして知られています。しかし、アップデートや変更が行われる際には、互換性の問題や新しい機能の導入に注意が必要です。

    問題の概要

    Alpine Linux 3.13 で Postfix 3.5.9-r0 にアップデートすると、デフォルトの hash 辞書タイプがサポートされなくなる問題が発生しています。

    解決方法

    1. /etc/postfix/main.cf 内の全ての hash または btree を使用するテーブルをサポートされている代替手段に変更します。多くの場合、lmdb が推奨される代替手段となります。

    例:

    alias_database = hash:/etc/postfix/aliases

    を

    alias_database = lmdb:/etc/postfix/aliases

    に変更します。

    1. そして、postmap コマンドを使用してルックアップテーブルを作成します。
    postmap lmdb:/etc/postfix/canonical

    結論

    技術の進化とともに、ソフトウェアのアップデートや変更は避けられません。しかし、その変更に迅速に対応し、正確な情報を共有することで、コミュニティ全体が利益を得ることができます。この記事が、Postfix と Alpine Linux の最新の変更に対応する際の手助けとなれば幸いです。

  • ECS: exec format error 問題への対処

    ECS: exec format error 問題への対処

    Dockerを使ったアプリケーションのデプロイは現代の開発プロセスの基盤となっています。しかし、Dockerイメージのビルドからデプロイまでの過程で予期しないエラーに遭遇することがあります。今回は、ECSでの「exec format error」というエラーの原因と解決方法を共有します。

    問題の発生

    特定のアーキテクチャ（例: ARM）でビルドされたDockerイメージを、異なるアーキテクチャ（例: amd64）の環境で実行しようとすると、「exec format error」というエラーが発生します。

    この問題は、特にM1チップを搭載したMacなどのARMアーキテクチャのマシンでDockerを使用してイメージをビルドする際によく見られます。ARMベースのイメージを、amd64アーキテクチャの環境（例: ECS）で実行しようとすると、上記のエラーが発生します。

    解決策: --platform オプションの使用

    Dockerビルド時に、--platformオプションを使用してアーキテクチャを明示的に指定することで、この問題を解決することができます。

    例:

    docker build --platform linux/amd64 -f Dockerfile -t your-image-name .

    このオプションを使用することで、イメージは指定されたアーキテクチャでビルドされます。

    まとめ

    アーキテクチャの違いは、Dockerイメージのビルドとデプロイの間で予期しない問題を引き起こすことがあります。この問題を回避するためには、ビルド時にターゲットアーキテクチャを明示的に指定することが重要です。--platformオプションを活用して、ECSやその他のデプロイ環境でのエラーを防ぎましょう。

  • AWS X-Ray と X-Amzn-Trace-Id の深掘り

    AWS X-Ray と X-Amzn-Trace-Id の深掘り

    AWS X-Ray は、アプリケーションの動作を可視化し、ボトルネックや問題点を特定するためのサービスです。X-Ray のトレース機能をフル活用するためには、X-Amzn-Trace-Id ヘッダの正しいフォーマットと使用が不可欠です。この記事では、このヘッダのフォーマットと、それを正しく使用するためのヒントや注意点について解説します。

    1. X-Amzn-Trace-Id のフォーマット

    ヘッダは以下の構成要素からなります：

    • Root：トレースのユニークな識別子。例: 1-<8桁の16進数のエポックタイムスタンプ>-<24文字のランダム値>
    • Parent：呼び出し元のサービスのセグメントID（オプション）。
    • Sampled：トレースデータをX-Rayに送信するかどうかを示すフラグ。通常、0（送信しない）または1（送信する）のいずれかの値を持ちます。

    2. エポックタイムスタンプと16進数

    Root の部分には、エポックタイムスタンプの16進数表現が必要です。この値は、UNIX時間（1970年1月1日からの秒数）を16進数に変換したものです。これにはシェルスクリプトを使用して簡単に取得できます：

    hex_time=$(printf '%x' $(date +%s))

    3. X-Ray への正確なログ表示のための注意点

    • 時間の正確さ：X-Amzn-Trace-Id のタイムスタンプが正確でないと、X-Ray には表示されますが、期待した時刻の範囲で表示されない可能性があります。
    • 16進数の確認：Root の3文字目は16進数でなければなりません。これを確認しないと、X-Ray はトレース情報を正しく処理できません。
    • トレースIDの生成：独自のアプリケーションやバッチ処理からリクエストを送る場合は、適切な X-Amzn-Trace-Id ヘッダを自分で生成する必要があります。

    4. サンプルのシェルスクリプト

    以下は、curl コマンドを使用して適切な X-Amzn-Trace-Id ヘッダを付与したリクエストを送るためのサンプルスクリプトです：

    bash
    #!/bin/bash

    # エポックタイムスタンプの16進数取得
    hex_time=$(printf '%x' $(date +%s))
    trace_id="Root=1-$hex_time-a5d9f372e21340000000000001;Sampled=1"

    # curl コマンド実行
    curl --location 'https://your-api-endpoint.com/path' \
    --header 'Content-Type: application/json' \
    --header "X-Amzn-Trace-Id: $trace_id" \
    --data 'YOUR_PAYLOAD_HERE'

    5. まとめ

    AWS X-Ray をフルに活用するためには、正確な X-Amzn-Trace-Id ヘッダの生成と送信が不可欠です。特に、エポックタイムスタンプの正確さや16進数のフォーマットが重要です。この記事の情報を使用して、X-Ray でのトレースデータの可視化を効果的に行うことができるでしょう。

  • Autifyでの高度な待機処理: 非活性ボタンを活性化するまで

    はじめに

    テストオートメーションツール「Autify」は、非技術者でも簡単にWebアプリケーションのE2Eテストを構築・実行することができるツールです。しかしながら、特定の操作が完了するまで待機するといったシチュエーションでは、JavaScriptステップを利用することでより高度な制御が可能になります。

    今回は、あるボタンが非活性（disabled）から活性になるのを待つシチュエーションを例に、Autify内でのJavaScriptステップの作成方法を解説します。

    シチュエーション

    テストシナリオ内で、あるアクションの後、ボタンが活性化されるのを30秒間待ち、活性になったらその後のステップへ進むというシチュエーションを想定します。

    解決方法

    Autify内でJavaScriptステップを作成し、以下のスクリプトを利用します。

    var xpath = "/html/body/div[1]/div/div/div/div[1]/div/div[3]/div[2]/button";
    var element = document.evaluate(xpath, document, null, XPathResult.FIRST_ORDERED_NODE_TYPE, null).singleNodeValue;
    if (!element) {
    throw new Error("Error: cannot find the element with xpath(" + xpath + ").");
    }
    var endTime = Date.now() + 30000;
    (function checkIfEnabled() {
    if (Date.now() > endTime) {
    throw new Error("Timeout: Button was not enabled within 30 seconds.");
    }
    if (!element.disabled) {
    return;
    } else {
    setTimeout(checkIfEnabled, 500);
    }
    })();

    まとめ

    Autifyは直感的なインターフェースでテストシナリオを組むことができますが、JavaScriptステップをうまく活用することで、さらに柔軟なテストの実現が可能となります。このようなテクニックを駆使して、品質の高いテストオートメーションを構築しましょう。

  • AWS SAM CLIでDockerがUnreachableな場合の解決

    AWS SAM CLIでDockerがUnreachableな場合の解決

    はじめに

    AWS Serverless Application Model (SAM) は、サーバレスアプリケーションを簡単に作成、テスト、デプロイするためのフレームワークです。しかし、時々 sam build --use-container コマンドを使用したときに、”Docker is unreachable. Docker needs to be running to build inside a container.”というエラーメッセージが表示されることがあります。

    Dockerが実行中であり、Dockerのバージョン情報が正しく表示されているにもかかわらず、このエラーが発生することがあります。このブログでは、その問題の解決法について説明します。

     

    問題の再現

    以下のようなコマンドを実行してみました。

    $ sam build --use-container

    そして、以下のエラーが表示されました。

    Error: Docker is unreachable. Docker needs to be running to build inside a container.

    しかし、Dockerは実行中であり、バージョン情報も正しく表示されます。

    $ docker ps
    CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

    $ docker --version
    Docker version 23.0.5, build bc4487a

    解決法

    解決法は、Dockerのコンテキストを確認し、適切に設定することです。

    まず、現在のDockerのコンテキストを表示します。

    $ docker context ls

    次に、適切なDockerのエンドポイントに対する環境変数 DOCKER_HOST を設定します。

    $ DOCKER_HOST=unix:///Users/sumito.tsukada/.docker/run/docker.sock sam build --use-container

    これにより、Dockerが適切に認識され、SAM buildコマンドが正常に実行されるはずです。

    結論

    DockerとAWS SAM CLIの連携は、サーバレスアプリケーションの開発をスムーズに進める上で非常に便利です。しかし、時々ツール間の接続に問題が生じることがあります。そのような場合は、環境変数を適切に設定し直すことで問題が解決することがあります。ぜひ、この記事があなたの問題解決の一助となることを願っています。

  • ターミナルを開いたら自動でtmuxを起動させる

    ターミナルを開いたら自動でtmuxを起動させる

    はじめに

    tmuxを起動させることを自動化して、新しいターミナルウィンドウを開くと同時にtmuxが起動するように設定する方法を紹介します。

    今回はmacOSのiTerm2を例に説明します。

    ステップバイステップのガイド

    ステップ1: iTerm2を開く

    まずはiTerm2を開きましょう。もしまだインストールしていない場合は、公式サイトからダウンロードしてインストールしてください。

    ステップ2: Preferencesを開く

    次に、上部メニューから「iTerm2」をクリックし、「Preferences」を選択します。またはキーボードショートカットのcommand+,を使用することもできます。

    ステップ3: プロファイル設定を開く

    「Profiles」タブをクリックしてください。左側のプロファイルリストから、使用したいプロファイル（「Default」を使用している方が多いと思います）を選択します。

    ステップ4: コマンド設定を行う

    「General」タブの「Command」セクションに進みます。「Send text at start」にtmuxと入力し、設定を保存します。

    これで設定は完了です。

    ステップ5: 新しいターミナルウィンドウを開く

    新しいターミナルウィンドウ（新しいタブや新しいウィンドウでも構いません）を開いてみましょう。自動的にtmuxが起動するはずです。

    まとめ

    この設定を行うことで、毎回手動でtmuxコマンドを打つ必要がなくなります。

    一度の設定でこれ以降の作業を効率化できるので、ぜひお試しください。