タグ: ElasticIP

  • WS 上に ORCA(WebORCA)を構築した1日|EC2(Ubuntu)での実践手順とトラブルシューティング

    今日は、AWS 上に ORCA(WebORCA)を構築する作業に取り組みました。
    以前から Windows Server は構築済みでしたが、今回は Ubuntu サーバ上で ORCA をフルインストールし、WebORCA がブラウザから動作するところまで を達成しました。

    AWS と医療システム構築の良い練習にもなり、トラブルもいくつか発生しましたが、結果としてクラウド版 ORCA 環境が完成しました。

    1. 本日のゴール

    • AWS EC2(Ubuntu 22.04)へ ORCA をインストール
    • apt-line・keyring の追加
    • weborca-install によるモジュール導入
    • WebORCA(http://xxx.xxx.xxx.xxx:8000)にブラウザアクセス
    • Elastic IP を割り当てて DNS 化
    • Windows Server(同一VPC)からも疎通確認

    2. 使用した EC2 の構成

    • OS:Ubuntu 22.04 LTS(HVM)
    • インスタンスタイプ:t2.medium
    • ディスク:40GB(後から拡張可能)
    • セキュリティグループ
      • SSH(22):自分のIPのみ
      • 8000:必要なIPのみ後から開放
    • キーペア:新規作成(pem)

    3. インスタンス起動 → SSH ログインまで

    ● キーペア作成時の注意

    PuTTY形式(ppk)は不要。
    PowerShell から直接 SSH で接続できるため pem でOK。

    接続例:

    ssh -i .\mykey.pem ubuntu@ElasticIP
    

    4. ロケール設定

    初期状態では LANG=C.UTF-8 だったため、日本語ロケールへ変更。

    sudo apt update
    sudo apt install language-pack-ja
    sudo update-locale LANG=ja_JP.UTF-8
    

    確認:

    locale
    

    LANG=ja_JP.UTF-8 になっていればOK。


    5. ORCA 用 apt-key(keyring)と apt-line の追加

    ORCA公式の手順書に従う。

    ● Keyring配置

    sudo -i
    wget https://ftp.orca.med.or.jp/pub/ubuntu/archive.key -O /etc/apt/keyrings/jma.asc
    ls /etc/apt/keyrings/
    

    jma.asc が見えれば成功。

    ● apt-line 設定

    cd /etc/apt/sources.list.d/
    wget https://ftp.orca.med.or.jp/pub/ubuntu/jma-receipt-weborca-jammy10.list
    

    6. パッケージ更新

    apt update
    apt dist-upgrade
    

    ここで“GRUB の選択”画面が出たが、そのままデフォルトで進行。
    アップグレード後、以下ログで完了:

    Restarting services...
    No user sessions are running outdated binaries.
    

    7. ORCA(WebORCA)のインストール

    ● 本体インストール

    sudo apt install -y jma-receipt-weborca
    

    ● モジュール導入

    sudo weborca-install
    sudo weborca-install -l
    

    バージョン例:

    MiddleWare 20230117-5
    Compiler   20221216-3
    Application 20230402-1
    

    8. WebORCA 起動確認(最初のトラブル)

    ブラウザで:

    http://10.0.0.37:8000/
    

    Windows Server から開こうとして アクセス不可

    ● 原因

    セキュリティグループが「自分のローカルIPのみ許可」になっていた。

    ● 解決

    インバウンド 8000 に 同じVPCの Windows Server のセキュリティグループを許可


    9. Elastic IP の割り当てと DNS 登録

    • EC2 に Elastic IP をアタッチ
    • お名前.com で Aレコードを作成
    • 反映後、下記URLでアクセス可能に:
    http://(独自ドメイン):8000/
    

    nslookup で疎通確認:

    nslookup your.domain.jp
    

    10. 今日のトラブルと解決方法まとめ

    ① apt-key が非推奨と言われる

    → ORCA公式どおり /etc/apt/keyrings に配置する方式で解決。


    ② GRUBの選択画面が出て驚く

    → Ubuntuの dist-upgrade でよくある挙動。
     既定のままで問題なし。


    ③ WebORCA にアクセスできない

    → セキュリティグループの許可範囲の問題。
     VPC内の Windows Server のIPを明示的に許可。


    ④ PowerShellでSSH接続時にキーペア指定の書式を間違えた

    → 正しい書式:

    ssh -i .\mykey.pem ubuntu@IP
    

    11. 今日得られた成果

    • AWS上で ORCA フル構築が完了
    • Ubuntu / apt-line / keyring の理解が深まった
    • AWS のセキュリティグループ設計を体験
    • ElasticIP+DNS を設定し、医療用システムとして実運用可能な構成へ
    • Windows Server → Ubuntu への疎通確認
    • 実務ではできない自由な実験環境が確立
  • AWS で RSBASE 動作環境を構築した一日:S3・EC2・DNS・AMI までの実録ログ

    今日は、自分が以前運用していた医療用ファイリングソフト「RSBASE」を、AWS 上の Windows Server に構築する作業を進めた。
    ローカルでは長年扱ってきた環境だが、AWS でゼロから構築するとなると、
    S3、IAM、EC2、ストレージ、DNS と幅広い知識が求められ、なかなか濃い一日になった。


    1. S3 バケットの作成とローカル → AWS へのファイル転送

    RSBASE 本体はフォルダ構造が重要で、そのまま EC2 に持っていく必要がある。
    当初は Windows から aws s3 sync を使って直接コピーしようとしたが、
    ディレクトリ構造が崩れてしまう問題が発生

    ▶ Synce失敗例(階層が壊れる)

    aws s3 sync E:\ s3://aws-yasuda-work-bucket-tokyo/installers/
    

    数万ファイルをコピーしたが、
    「リンク」「ショートカット」「一部のディレクトリ」などが乱れ、
    RSBASE のように “素の構造” が命のソフトでは致命的。


    2. 解決策:ZIP 化して S3 へアップロード

    最終的に取った方法はとてもシンプル:

    ✔ 圧縮(ZIP)

    → アップロード
    → EC2 で解凍して配置

    ZIP 化したところ約 3GB にまとまり、確実にコピーできた。

    ▶ アップロードコマンド

    aws s3 cp .\rsbase.zip s3://aws-yasuda-work-bucket-tokyo/installers/
    

    ▶ EC2 側でダウンロード

    aws s3 cp s3://aws-yasuda-work-bucket-tokyo/installers/rsbase.zip .
    

    この方式が一番安定し、S3 の PUT/GET の課金も最小に抑えられる。


    3. EC2 Windows Server のセットアップ

    ✔ IAM ロール(S3 アクセス権)を追加

    途中、Unable to locate credentials が出ることもあったが、
    EC2 の IAM ロールが正しく設定されていれば認証情報は不要。

    ▶ 反映確認コマンド

    aws sts get-caller-identity
    

    結果が以下になっていれば EC2 が IAM ロールを使っている状態:

    "Arn": "arn:aws:sts::<アカウントID>:assumed-role/EC2-SSM-Role/i-xxxxx"
    

    4. EBS 増設(Eドライブ)

    構築開始後に気づいたが、
    初期構成では C ドライブしかなく RSBASE を置くには狭い。
    そこで EBS を 20GB 追加し、Eドライブとして利用。

    手順:

    1. EC2 → ボリューム → 新規作成
    2. 「アタッチ」
    3. Windows でディスク管理 → 初期化 → NTFS でフォーマット

    5. RSBASE の配置と動作確認

    ZIP を解凍し、必要なパスへ配置。
    RSBASE の Apache を起動すると EC2 内では正常動作 を確認。


    6. ローカル PC からのアクセス:80番を開ける

    EC2 のセキュリティグループに Windows Server 用に HTTP(80) を追加。

    ただし、全世界に開放するのは危険なので
    MyIP(自身のグローバルIP限定) に設定。

    Windows Firewall も忘れずに

    GUI から

    受信の規則 → 新しい規則 → TCP 80 → 許可
    

    設定後、ローカルPCから

    http://<EC2のパブリックIP>
    

    でアクセス成功。


    7. Elastic IP(固定IP)を割り当てる

    一度アクセスできても、EC2 の再起動で IP が変わるので、
    Elastic IP を割り当てて固定化した。

    割り当て後、次のように表示されていれば OK。

    パブリック IPv4: 〇〇〇.〇〇〇.〇〇〇.〇〇〇(Elastic IP)
    

    8. DNS 設定(Route53 → お名前.com DNSへ切り替え)

    本命は Route53 に移すことだったが、
    お名前.com のドメインが「ネームサーバの変更不可状態」 になっており移行できなかった。

    理由:
    レンタルサーバ(WordPress)が同じドメインを使っており、
    ネームサーバ変更がロックされていたため。

    そのため、今回の方法:

    お名前.com の DNS に A レコードを追加する方式へ変更

    rsbase.medical-engineering.jp → <Elastic IP>
    TTL:600
    

    反映は最大 24 時間程度。


    9. バックアップ(AMI 作成)

    最後に EC2 の AMI を作成。
    説明文に日本語を入れるとエラー:

    Character sets beyond ASCII are not supported.
    

    対策:
    → 英字のみで AMI 名・説明文を入力
    → 再作成して成功。

    AMI 作成中はインスタンスが再起動される場合があるが問題なし。


    まとめ:今日の成果

    • S3 による RSBASE 配布方式の確立
    • EC2 Windows Server で RSBASE 動作確認
    • EBS 増設で十分なストレージ確保
    • HTTP 公開と Windows Firewall 設定
    • Elastic IP により固定アクセスが可能に
    • DNS は Route53 ではなく お名前.com DNS を継続使用
    • AMI を作成し、復元可能な状態になった

    AWS の基礎からネットワーク、バックアップまで
    一通りの構築作業を実践できた濃い日となった

    明日は DNS が浸透しているはずなので、
    http://rsbase.medical-engineering.jp/ でアクセスできるのを楽しみにしたい。