カテゴリー: tech

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

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

    はじめに

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

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

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

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

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

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

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

    注意点

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

    まとめ

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

  • Dockerビルドエラーの解消: ストレージ不足とその対処法

    Dockerビルドエラーの解消: ストレージ不足とその対処法

    はじめに: Dockerを利用している際に、ビルドプロセス中に突如としてエラーが発生することがあります。この記事では、特にapt-get updateapt-get install コマンドの実行中に起きたエラーと、それを解消するために行った対処法について解説します。

    問題の発生: 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 system prune --volumes

    このコマンドは、未使用のコンテナ、ネットワーク、イメージ、およびボリュームを削除し、必要な空き容量を確保します。

    結果: コマンドの実行後、再度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 でのトレースデータの可視化を効果的に行うことができるでしょう。

  • 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コマンドを打つ必要がなくなります。

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

     

     

  • jqを使ったJSONデータの柔軟な操作: ユーザーの属性値の動的変更

    jqを使ったJSONデータの柔軟な操作: ユーザーの属性値の動的変更

    はじめに

    jqはコマンドラインツールで、JSONデータをパースしたり操作したりするのに非常に便利です。今回は、特定のユーザーの属性(タグリスト)から特定の要素を削除する、という具体的なタスクを通じて、jqの使い方について解説します。

    JSONデータの説明

    まずは問題を理解するために、私たちが操作するJSONデータを見てみましょう。以下のような形式のデータです:

    {
    "data": {
    "users": [
    {
    "username": "Alice",
    "tags": "tag1, tag2"
    },
    {
    "username": "Bob",
    "tags": "tag2"
    },
    {
    "username": "Charlie"
    }
    ]
    }
    }

    このデータは、”data”というキーの中に、”users”という配列があります。各ユーザーは”username”と”tags”という2つの属性を持つことができます。

    目標の説明

    ここでの目標は、特定のユーザー(この例では”Alice”)のタグリストから特定のタグ(この例では”tag2″)を削除することです。このようなタスクは、例えば特定のユーザーのロールや権限、ステータスなどを更新する際によく遭遇します。

    jqコマンドの解説

    目標を達成するために、以下のようなjqコマンドを使用します。

    jq -r --arg username "Alice" --arg delete_tag "tag2" '
    .data.users |= map(
    if .username == $username then
    if .tags? | contains($delete_tag) then
    if .tags == $delete_tag then
    del(.tags)
    else
    .tags |= gsub($delete_tag + ", "; "")
    | .tags |= gsub(", " + $delete_tag; "")
    end
    else
    .
    end
    else
    .
    end
    )
    '
    users.json

    ここで”-r”オプションは、出力結果をraw形式(エスケープされていない形式)で出力することを指定します。

    “–arg username “Alice”” と “–arg delete_tag “tag2″” では、コマンド実行時にjqに変数を渡しています。これにより、このコマンドは特定のユーザー名と削除するタグを動的に指定できます。

    そして、”.data.users |= map(…)”では、全てのユーザー(.data.usersの配列)を一つずつ処理しています。この”map”関数は、配列の全ての要素に対して指定した処理(ここでは後続のif文全体)を適用します。

     

    jqコマンドの詳細

    ここで、このjqコマンドがどのように動作しているのかを詳しく見ていきましょう。

    まず、”if .username == $username then”という行では、現在処理しているユーザーのusernameが指定したusernameと一致するかどうかを確認します。もし一致すれば、そのユーザーに対して更なる処理(後続のif文)を行います。

    次に、”if .tags? | contains($delete_tag) then”という行では、現在処理しているユーザーがtags属性を持ち、その中に削除するタグが含まれているかを確認します。ここで、”?”演算子を使うことで、もしユーザーがtags属性を持っていなければエラーにせずにnullを返します。

    そして、もしユーザーが削除するタグだけを持っている場合(つまり、そのユーザーのtagsが削除するタグと全く同じである場合)、”if .tags == $delete_tag then del(.tags)”という部分でそのtags全体を削除します。

    もしユーザーが削除するタグを含むが、他にもタグを持っている場合(つまり、そのユーザーのtagsが削除するタグを含むカンマ区切りの文字列である場合)、

    .tags |= gsub($delete_tag + ", "; "")
    | .tags |= gsub(", " + $delete_tag; "")

    という部分で削除するタグを取り除きます。ここで、”gsub”関数は、第一引数の正規表現にマッチする全ての部分を第二引数に置き換えます。つまり、この行では、タグリストから削除するタグを取り除いています。

    まとめ

    以上が、jqを使ってJSONデータを操作する具体的な例です。この例を通じて、jqの強力さと柔軟性を理解していただけたと思います。JSONデータを操作する必要がある場合、是非jqをお試しください。

  • FlaskとQueueを用いたタスク管理の実装

    FlaskとQueueを用いたタスク管理の実装

    PythonのFlaskフレームワークは、その軽量さと拡張性から、さまざまなウェブアプリケーションで用いられています。今回はFlaskを使用したシステムで、Pythonの組み込みモジュールであるQueueを利用して、タスク管理を効率的に行う方法について解説します。

    この記事で取り扱う主要なテーマは以下の通りです:

    • PythonのQueueを使ったタスク管理
    • Queueとスレッドを組み合わせた非同期処理

    PythonのQueueを使ったタスク管理

    Pythonのqueue モジュールは、FIFO(First-In, First-Out)方式のキューを実装しており、スレッド間でデータの受け渡しを行う際に特に有用です。以下に具体的なコードを示します。

    import queue
    import threading
    # グローバルにキューを作成
    task_queue = queue.Queue()
    def worker():
    while True:
    task = task_queue.get()
    if task is None:
    break
    # ここでタスクを処理
    task_queue.task_done()
    # ワーカースレッドを作成し、実行
    worker_thread = threading.Thread(target=worker)
    worker_thread.start()
    @app.route('/task', methods=['POST'])
    def add_task():
    task_data = request.get_json()
    task_queue.put(task_data)
    return jsonify({'status': 'queued'})

    このコードでは、新たなタスクがPOSTリクエストとして/taskエンドポイントに送信されると、そのタスクはキューに追加されます。一方、バックグラウンドで実行されているワーカースレッドは、キューからタスクを取り出して処理を行います。

    Queueとスレッドを組み合わせた非同期処理

    Queueとスレッドを組み合わせることで、Flaskアプリケーションでの非同期タスク管理を実現できます。これにより、リクエストを迅速に受け付けつつ、時間のかかる処理をバックグラウンドで並行して実行することができます。

    この記事が皆さんのFlaskとPythonのプロジェクトに役立つことを願っています