カテゴリー: tech

発明家の挑戦

この記事を読んで学べること:

「I was wondering when you’d show up! No one wants to try my Telepod.」というフレーズを通じて、英語の日常会話でよく使われる表現を学びます。
相手の行動や反応に対する期待と失望を伝える表現を理解します。

今回の表現: “Lucca: I was wondering when you’d show up! No one wants to try my Telepod.”

日本語訳: 「ルッカ: いつ来るのかと思ってたよ！誰も私のテレポッドを試したがらないの。」

文法解析: この文では “I was wondering” という過去進行形を使い、過去のある時点での考えや疑問を表しています。”when you’d show up” は間接疑問文で、”you would show up” の短縮形です。”No one wants to try” は否定文で、主語が “No one” の場合、動詞は三人称単数の形になります。

他の表現との違い:

オリジナルの表現	似た表現	使い方の違い	例文
was wondering	was thinking	“wondering” は疑問や好奇心が含まれているが、 “thinking” は単なる考えや計画を指す。	“I was thinking about going to the beach tomorrow.” （明日、ビーチに行こうと思ってたんだ。）
show up	turn up	“show up” は計画された出現や参加を指し、 “turn up” は予期せぬ現れを示すことが多い。	“He didn’t turn up to the meeting yesterday.” （彼は昨日の会議に現れなかった。）

英語学習者として覚えておくべきポイント: 「I was wondering」や「show up」は、英語の会話でよく使われる便利なフレーズです。特に「I was wondering」は、丁寧な疑問の表現として用いられることが多く、ビジネスシーンでも活用できます。「No one wants to try」は、あるアクションや提案に対する興味や意欲の欠如を示すのに使えますが、文脈に応じて慎重に使う必要があります。ビジネス的なコミュニケーションでは、相手の感情や立場を尊重しつつ、正直かつ効果的なフィードバックを提供することが重要です。

2024年1月27日

気づかぬ心 – 「You’re an oblivious one, aren’t you? Well, never mind then.」の表現を学ぶ

この記事を読んで学べること:

「oblivious」という言葉の意味と会話での使用法
相手が注意を払っていない時の優しい指摘の仕方
英語での間接的な表現を用いたフィードバックの技術

今回の表現: “You’re an oblivious one, aren’t you? Well, never mind then.”

日本語訳: 「あなたは気づかないタイプですね。まあ、いいですけど。」

文法解析: このフレーズは、「oblivious」を用いて相手が何かに気づいていないことを指摘し、「aren’t you?」でその事実を相手に問いかけます。続く「Well, never mind then.」は、その状況を受け入れ、話を進める意思を示しています。

他の表現との違い:

オリジナルの表現	似た表現	使い方の違い	例文
You’re an oblivious one	You seem distracted	「You’re an oblivious one」は相手が一般的に気づかない性質があることを示し、「You seem distracted」はその瞬間に集中していない様子を指摘します。	You seem distracted today, is everything alright?

覚えておくべきポイント: 「You’re an oblivious one, aren’t you?」という表現は、相手が何かを見落としていることを指摘する際に使われることがありますが、この言い方は非常にカジュアルで、親しい間柄でなければ不快に感じられる可能性があります。会話においては、このような表現を使う前に、相手との関係性や文脈を考慮することが重要です。

2024年1月16日

AWS LambdaでGo1.xランタイムからAmazon Linux 2へスムーズに移行する方法
はじめに

AWS Lambdaは、サーバーレスコンピューティングを可能にするAWSの重要なサービスですが、Lambda はGo1.xランタイムの廃止とprovided.al2ランタイムへの移行を予定しています。

この記事では実際に変更した際に修正した箇所についてまとめます。

変更内容

公式ブログと、クラメソさんの記事を参考に以下の通り変更しました
```
Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Metadata:
      BuildMethod: go1.x 
    Properties:
      CodeUri: hello-world/ # folder where your main program resides
      Handler: bootstrap
      Runtime: provided.al2
      Architectures:
        - x86_64
```
sam deploy 後

以下のようなエラーが発生しました
```
Phase: invoke Status: error Error Type: Runtime.Unknown
```
問題への対処

調べたところ、 github.com/aws/aws-lambda-goが古いとal2 runtimeに対応してないことがわかりました。そのため、以下の対処を行いました。
```
go get github.com/aws/aws-lambda-go
go mod download gopkg.in/yaml.v3 
```
古い aws-lambda-go は provided.ai2 ランタイムには対応してないようで細心にする必要があったようです。
2023年12月22日
Poetry依存関係の不整合エラー解消ガイド：原因と対処法
はじめに

Pythonプロジェクトにおいて、依存関係管理ツールとして広く利用されているPoetryですが、環境構築やビルドプロセスの際に依存関係の不整合が原因でエラーが発生することがあります。本記事では、Poetry使用時に発生する依存関係の不整合エラーに焦点を当て、エラーメッセージの解析、原因の特定、そして具体的な対処方法について詳しく解説します。これにより、ビジネスシーンでの開発効率向上とシステムの安定運用に貢献します。

問題の概要

開発プロジェクトにおいて、以下のようなエラーメッセージが表示された場合、依存関係の不整合が原因でビルドプロセスが失敗している可能性があります。
```
Warning: poetry.lock is not consistent with pyproject.toml. You may be getting improper dependencies. Run `poetry lock [--no-update]` to fix it. Because hogehoge depends on psycopg2-binary (2.9.9) which doesn't match any versions, version solving failed.
```
このエラーメッセージは、二つの主な問題を示しています。
1. poetry.lock と pyproject.toml の不整合
2. psycopg2-binary のバージョン指定の不一致
原因の特定

1. poetry.lock と pyproject.toml の不整合
- 概要:
  Poetryは、pyproject.toml に記載された依存関係情報を元に poetry.lock ファイルを生成し、プロジェクトの依存関係を固定化します。しかし、この2つのファイル間で不整合が生じると、依存関係の解決が正しく行われず、ビルド時にエラーが発生します。
- 背景:
  コードの変更やパッケージのバージョン更新に伴い、pyproject.toml が変更されたにもかかわらず、poetry.lock が更新されない場合にこの問題が発生します。
2. psycopg2-binary のバージョン問題
- 概要:
  エラーメッセージにあるように、psycopg2-binary の指定されたバージョン「2.9.9」が、利用可能なバージョンリストと一致しないため、依存関係の解決に失敗しています。
- 背景:
  特定のパッケージに対して厳密なバージョン指定を行うと、リポジトリにそのバージョンが存在しない場合や、互換性のあるバージョンがリリースされている場合に問題が発生します。
対処方法

1. poetry.lock と pyproject.toml の不整合の修正
- 手順:
  以下のコマンドを実行し、poetry.lock ファイルを pyproject.toml に合わせて再生成します。bashコピーする編集するpoetry lock --no-update
- ポイント:
  --no-update オプションを使用することで、既存の依存関係を最新バージョンに更新することなく、現状の設定と整合させることができます。
2. psycopg2-binary のバージョン指定の見直し
- 手順:
  プロジェクトの pyproject.toml を確認し、psycopg2-binary のバージョン指定を柔軟な指定（例: ^2.9）に変更することを検討します。
- ポイント:
  柔軟なバージョン指定により、互換性のある最新のバージョンが自動的に選定されるため、依存関係の解決がスムーズに進む可能性が高まります。
3. 依存関係の再インストール
- 手順:
  上記の修正を行った後、以下のコマンドで依存関係を再インストールし、エラーが解消されたかを確認します。
  poetry install
- ポイント:
  再インストールにより、全ての依存パッケージが正しく設定され、ビルドプロセスが正常に進行する環境を構築できます。
4. テストと検証
- 手順:
  ローカル環境でビルドプロセスや実行テストを行い、変更が正しく反映され、エラーが解消されていることを確認します。
- ポイント:
  本番環境に展開する前に、十分なテストを実施することで、後続のトラブルを未然に防止できます。
まとめ

本記事では、PythonプロジェクトにおけるPoetryの依存関係管理で発生する不整合エラーについて、その原因と対処法を詳しく解説しました。
- poetry.lock と pyproject.toml の不整合 は、依存関係の固定化を行う際に注意が必要です。
- psycopg2-binary のバージョン指定の不一致 は、柔軟なバージョン指定を活用することで解決が期待できます。
これらの対処法を実践することで、依存関係管理のトラブルシューティングが円滑に進み、ビルドプロセスの効率化とシステムの安定運用が実現されます。
今後も、Pythonプロジェクトでの依存関係管理における最適なプラクティスを追求し、業務の生産性向上に努めましょう。
2023年12月16日
Ubuntuにおけるタイムゾーン設定の自動化：手動選択を回避する方法
Ubuntuにおけるタイムゾーン設定の自動化：手動選択を回避する方法

Ubuntuを使用する際、特にサーバー環境やDockerコンテナを設定する場合、タイムゾーンの設定が重要なステップです。しかし、インストールやアップデートの際に表示されるタイムゾーンの選択画面は、自動化された環境では不便であり、効率を下げる要因となります。この記事では、Ubuntuにおけるタイムゾーンの設定を自動化し、手動での選択プロセスを回避する方法を解説します。

タイムゾーンを設定しないと以下の様な対話式の画面が表示されます。
```
Configuring tzdata
------------------

Please select the geographic area in which you live. Subsequent configuration questions will narrow this down by presenting a list of cities, representing the time zones in which they are located.

  1. Africa  2. America  3. Antarctica  4. Australia  5. Arctic  6. Asia  7. Atlantic  8. Europe  9. Indian  10. Pacific  11. SystemV  12. US  13. Etc
Geographic area: 
```
タイムゾーン設定の重要性

サーバーやアプリケーションは、ログのタイムスタンプ、スケジューリングタスク、時間に依存する処理など、多くの機能がシステムのタイムゾーン設定に依存しています。不正確なタイムゾーン設定は、データの整合性の問題や、予期せぬエラーの原因となり得ます。

手動選択プロセスの問題点

Ubuntuのインストールやアップグレード中に表示されるタイムゾーンの選択画面は、対話型のインターフェースを提供します。これは、通常のデスクトップ使用では問題ありませんが、自動化された環境や非対話型のセットアップでは不都合です。このプロセスを自動化することで、スムーズで効率的な環境構築が可能になります。

タイムゾーンの自動設定方法

以下のステップに従って、Ubuntuでタイムゾーンを自動的に設定することができます。

ステップ1: タイムゾーンの環境変数を設定

まず、タイムゾーンを環境変数として設定します。例えば、日本のタイムゾーンを設定する場合は以下のようにします。
```
export TZ=Asia/Tokyo
```
ステップ2: システムのタイムゾーンファイルを更新

次に、システムのタイムゾーン設定ファイルを更新します。

対応するタイムゾーンのファイルへのシンボリックリンクを作成します。
```
ln -snf /usr/share/zoneinfo/$TZ /etc/localtime
```
ステップ3: タイムゾーン設定を永続化

最後に、設定を永続化するために、タイムゾーンの値を/etc/timezoneファイルに書き込みます。

echo $TZ > /etc/timezone

まとめ

この方法により、Ubuntuのタイムゾーン設定を自動化し、手動での選択を回避することができます。これは、サーバーのセットアップ、Dockerコンテナの構築、または任意の自動化されたデプロイメントプロセスにおいて、時間と労力を節約する効果的な手段です。
2023年12月1日
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を最新バージョンにアップグレードすることです。この記事が、同様の問題に直面している開発者の助けになることを願っています。
2023年12月1日
Dockerの未タグ付けイメージを一括削除：ストレージの最適化方法

はじめに

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

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

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

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

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

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

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

注意点

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

まとめ

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

2023年10月13日
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のトラブルシューティングに関する知識とスキルは、今後の開発・運用において不可欠な要素となるでしょう。
2023年10月12日
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キーを安全に管理し、その有効性を確認することができます。これにより、プロジェクトのセキュリティを維持しながらリモートサーバーへのアクセスを簡単に管理できます。
2023年10月11日
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 の最新の変更に対応する際の手助けとなれば幸いです。
2023年10月4日

カテゴリー: tech

はじめに

変更内容

はじめに

問題の概要

原因の特定

1. poetry.lock と pyproject.toml の不整合

2. psycopg2-binary のバージョン問題

対処方法

1. poetry.lock と pyproject.toml の不整合の修正

2. psycopg2-binary のバージョン指定の見直し

3. 依存関係の再インストール

4. テストと検証

まとめ

Ubuntuにおけるタイムゾーン設定の自動化：手動選択を回避する方法

タイムゾーン設定の重要性

手動選択プロセスの問題点

タイムゾーンの自動設定方法

ステップ1: タイムゾーンの環境変数を設定

ステップ2: システムのタイムゾーンファイルを更新

ステップ3: タイムゾーン設定を永続化

まとめ

はじめに

エラーの概要

解決策

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

結論

はじめに

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

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

注意点

まとめ

はじめに

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

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

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

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

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

問題の概要

解決方法

結論