0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@XYZXYZXYZ(kodomo daigaku)

rhelubiをkubernetesにデプロイしよう AI回答

0
Last updated at Posted at 2026-05-08

pod用のyamlファイルをAIに生成してもらう

まったくの素人
全然わかっていない
AIに作ってもらいました。

rhel9ubi.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: rhel9-ubi-deployment
  labels:
    app: rhel9-ubi
spec:
  replicas: 1
  selector:
    matchLabels:
      app: rhel9-ubi
  template:
    metadata:
      labels:
        app: rhel9-ubi
    spec:
      containers:
      - name: ubi9-container
        # 自分でビルドしたイメージ名、またはRed Hat公式イメージを指定
        image: docker.io/redhat/ubi9:latest
        # コンテナが即時終了するのを防ぐためのダミーコマンド
        command: ["/bin/sh", "-c", "while true; do sleep 3600; done"]
        resources:
          limits:
            cpu: "500m"
            memory: "512Mi"
          requests:
            cpu: "200m"
            memory: "256Mi"

ファイルを適用

kubectl apply -f rhel9ubi.yaml

備忘録

  1. Requests（リクエスト：最低保証）
    コンテナが起動するために 最低限必要な分量 です。
    cpu: "200m"： 0.2コア分を確保します（1000m = 1コア）。
    memory: "256Mi"： 256メガバイトを確保します。
    役割: Kubernetesはこの値を見て、空きリソースがあるノード（サーバー）を探してポッドを配置します。
  2. Limits（リミット：最大制限）
    コンテナが 使いすぎないように制限する上限値 です。
    cpu: "500m"： 0.5コア分までしか使わせません。これを超えようとすると、CPU使用率にブレーキがかかります。
    memory: "512Mi"： 512メガバイトまで。これを超えてメモリを使おうとすると、コンテナは強制終了（OOMKilled）されます。
    役割: 1つのコンテナが暴走して、同じサーバー上の他のコンテナに迷惑をかけるのを防ぎます。

ちなみによく忘れるから

labels と selector (紐付けの目印) ★ここが重要
ここにある2箇所のラベルは、必ず一致させる必要があります。

metadata:
  name: ubi-java-env            # 「設計図」の名前
spec:
  selector:
    matchLabels:
      app: ubi-java-pod         # ★これと
  template:
    metadata:
      labels:
        app: ubi-java-pod       # ★これだけ一致させる

ログインできました

kubectl exec -it rhel9-ubi-deployment-6bdd6f9fcd-q8tgc -- /bin/bash

Java17をインストールしたバージョンに変更

rhel9ubi.yaml
#以下だけ変更
image: registry.access.redhat.com/ubi9/openjdk-17:latest

ファイルを適用

kubectl apply -f rhel9ubi.yaml

ちなみにローリングアップデートされました。

rhel9-ubi-deployment-6bdd6f9fcd-q8tgc   1/1     Terminating   0                   25m
rhel9-ubi-deployment-d798cbf54-mcb2w    1/1     Running       0                   12s

jbossをインストールしてみよう

サーバまでファイルを持ってくる
ファイル名：jboss-eap-8.0.0.zip

ちなみにpod名はDeploymentを使っている場合は名前は固定できない。

Dockerfileを作ってみよう

FROM registry.access.redhat.com/ubi9/openjdk-17:latest

USER root

# 1. まずはJBossを解凍する
# jboss-eap-8.0.0.zipはコマンド実行する同じディレクトリに配置すること
COPY jboss-eap-8.0.0.zip /opt/
RUN cd /opt && \
    jar -xf jboss-eap-8.0.0.zip && \
    rm jboss-eap-8.0.0.zip

# 2. ディレクトリができた後に、WARファイルをコピーする
COPY example.war /opt/jboss-eap-8.0/standalone/deployments/

# 3. 最後にまとめて権限を整える
RUN chown -R 185:0 /opt/jboss-eap-8.0 && \
    find /opt/jboss-eap-8.0/bin -name "*.sh" -exec chmod +x {} + && \
    chmod -R g+rwX /opt/jboss-eap-8.0

USER 185
ENV JBOSS_HOME=/opt/jboss-eap-8.0
#「コンテナが起動した瞬間に、必ず実行されるメインのコマンド」
ENTRYPOINT ["/opt/jboss-eap-8.0/bin/standalone.sh", "-b", "0.0.0.0"]

ENTRYPOINTが設定している場合

このコンテナにとっての「メインの仕事」は standalone.sh になっています。JBossは起動すると、動作ログを画面（標準出力）にリアルタイムで流し続ける性質があるため、Kubernetesは「JBossが画面に出しているもの ＝ コンテナのログ」

#JBOSSのログのみ表示される
kubectl logs pod名

Docker buildしよう

#コンテナの型を作る
docker build -t my-jboss-eap:8.3 .
# 一覧に表示されること
docker images

Docker saveしよう

1つのファイル（.tar）として書き出す操作

docker save my-jboss-eap:8.3 > /tmp/my-jboss.tar

tarファイルを他のサーバに持っていく

※今回はリポジトリサーバを立てていないのでローカルに

scp /tmp/my-jboss.tar xxx@192.168.x.x:/tmp

Docker loadしよう

loadしないと、DockerHub側のリポジトリを探しに行くため

#containerdの場合は
ctr -n k8s.io images import /tmp/my-jboss.tar
crictl images | grep jboss

#Dockerの場合は
docker load

warファイルを作成しよう

# 作業ディレクトリ作成
mkdir -p test-app/WEB-INF
cd test-app

vi index.jsp
index.jsp
<%@ page language="java" contentType="text/html; charset=UTF-8"
    pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>こんにちは世界！</title>
</head>
<body>
    <h1>こんにちは世界！</h1>
    <p><%
out.println(new java.util.Date()); //ここだけjava言語で記載
%></p>
</body>

#WARファイルに固める

jar -cvf example.war *

podにファイルをコピーしよう

kubectl cp example.war pod名:/opt/jboss-eap-8.0/standalone/deployments/

ちょっとどこか忘れたけど
サービス化していました。

jboss-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: jboss-service
spec:
  type: NodePort
  selector:
    app: rhel9-ubi  # Deploymentのラベルと一致させる
  ports:
    - name: http
      protocol: TCP
      port: 8080      # コンテナ側のポート
      targetPort: 8080
      nodePort: 30080 # ブラウザでアクセスする際のポート（30000-32767の間）
    - name: admin
      protocol: TCP
      port: 9990      # 管理画面用ポート
      targetPort: 9990
      nodePort: 30990 # ブラウザでアクセスする際の管理用ポート

kubectl apply -f jboss-service.yaml

打鍵確認しよう

curl http://Node名:30080/example/
# IP確認は
# kubectl get nodes -o wide

トラブル対応時に使用したコマンド

kubectl describe pod pod名
kubectl logs pod名 | grep -i dep
kubectl exec rhel9-ubi-deployment-5ddc54b7b4-tltmp -- ls -l /opt/jboss-eap-8.0/standalone/deployments/

ECRにアップロードしてみよう

リポジトリを作成する

aws ecr create-repository --repository-name my-jboss-repo

DockerがAWSへイメージを送信できるように認証を通します。

aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin アカウントID.dkr.ecr.ap-northeast-1.amazonaws.com

Login Succeededが表示する

docker tag my-jboss-eap:8.2 アカウントID.dkr.ecr.ap-northeast-1.amazonaws.com/my-jboss-repo
# 宛先住所は、マネコン→ECR→該当リポジトリで確認できます。
#アカウントID.dkr.ecr.ap-northeast-1.amazonaws.com/my-jboss-repo

ECRにpushする。

docker push 913524941301.dkr.ecr.ap-northeast-1.amazonaws.com/my-jboss-repo

CodeCommitへアップロード

まずはgitの準備

git --version
git version 2.52.0

codecommit用リポジトリ作成

※このタイミングでなくてもOK

aws codecommit create-repository --repository-name my-jboss-app-code

gitで履歴管理を開始する

git init

すべての変更を「次のコミット対象」として予約する

git add .

コミットする

git commit -m "First commit: JBoss app"
[master (root-commit) 2d926d1] First commit: JBoss app
 2 files changed, 14 insertions(+)
 create mode 100644 example.war
 create mode 100644 index.jsp

AWSのソースコード管理サービスである AWS CodeCommit にHTTPSで接続する際、「AWSの認証情報（アクセスキーなど）を使って自動でログインできるようにする」ための設定

細かく記載すると

git config --global
PC上のすべてのGitプロジェクトに適用する共通設定として保存します。

credential.helper
「認証情報をどこから取得するか」を指定する設定項目です。

!aws codecommit credential-helper
!: Gitの外部にあるシェルコマンドを実行するという合図です。

aws codecommit credential-helper: 認証に使う実際のツール（AWS CLI）です。ローカルにあるAWSの認証情報（IAMユーザー等）を使って、一時的なログイン情報を生成します。

$@: Gitがツールに渡す引数（リポジトリのURLなど）をそのまま引き継ぐための記法です。

git config --global credential.helper '!aws codecommit credential-helper $@'

CodeCommitが同じドメインで複数のリポジトリを管理しているため、リポジトリのパスごとに個別の認証を行うように指示する設定です

git config --global credential.UseHttpPath true

git remote add origin ...
ローカルのGitに対して、「このプロジェクトのリモートリポジトリ（送信先）は、このURLですよ」と登録するコマンドです (1.3.2) (1.3.8)。
origin: リモートリポジトリに付けるニックネームです (1.5.13)。慣習的に「origin」が使われます (1.5.8)。
URL: AWS CodeCommitの東京リージョンにある my-jboss-app-code というリポジトリの場所を指しています (1.3.6)。

git remote add origin https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/my-jboss-app-code

ローカルの変更を、先ほど登録した origin（AWS）へ送り出す操作です (1.5.10)。

「-u」
→ ついでに、今後 git push とだけ打てば、自動的に「masterをoriginに送る」というルールをPCに覚えさせる。

origin master: 「origin という場所にある master ブランチ」に送るという意味です (1.5.7)。

master は手元の名前: あなたの PC の中にある、現在の作業ブランチの名前です。
origin は外の名前: AWS という「場所」に付けたあだ名です。

# masterにあるファイルをorigin(AWS)にpushする
git push -u origin master
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?