서버 성능 테스트를 해야하는 업무가 발생하여 어떤식으로 진행했는지 공유 해보려고 합니다.
하루 기준 약 300만의 유저가 1~2일 동안 저희 서비스에 유입이될 수 있는 상황이였습니다.

이에 따라 3000000 / 24 / 60 / 60 1초에 약 34명이 유입될 수 있다고 단순하게 계산을 한 후

서버 성능 테스트를 진행해보기로 했습니다.

상황에 따라 어느 언어나 툴을 사용하던 시나리오를 잘 구성하여 체크하면 된다고하여

가장 효율적인 방법을 고민하게 되었고,

가장 자신 있는 C# Conole 프로젝트로 진행 해보려고 합니다.

시나리오

필수 요소인 회원가입 & 로그인 작업 이후 유저가 실제로 행동할 Task를 분석하여

시나리오를 구성해보았습니다.

 

1초에 30명 ~ 50명 유저가 유입된다.
모든 유저는 각 Task 당 약 1초의 delay로 진행된다.
A (로그인) -> B Task -> C Task -> D Task -> B Task -> C Task -> D Task -> Exit

 

성능 테스트용 봇 개발

.NET Console 프로젝트를 활용하여 개발 하였습니다.

using log4net;
using log4net.Config;
using Newtonsoft.Json.Linq;
using System;
using System.Collections.Generic;
using System.IO;
using System.Net.Http;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using System.Xml.Linq;

class PerformanceTestBot
{
    private static readonly ILog log = LogManager.GetLogger(typeof(PerformanceTestBot));
    private static readonly HttpClient client = new HttpClient();
    private const int userCountPerSecond = 30; // 초당 생성할 유저 수
    private static bool keepRunning = true;
    private static int userCounter = 1; // 생성 시작할 유저 id

    static async Task Main(string[] args)
    {
        // Log4net 초기화
        XmlConfigurator.Configure(new FileInfo("log4net.config"));
        log.Info("Starting performance test...");

        Console.CancelKeyPress += (sender, e) =>
        {
            e.Cancel = true;
            keepRunning = false;
            log.Info("Stopping user creation...");
        };

        await StartUserCreationLoop(userCountPerSecond);
        log.Info("Performance test completed.");
    }

    // 유저 생성 루프
    private static async Task StartUserCreationLoop(int userCountPerSecond)
    {
        while (keepRunning)
        {
            var tasks = new List<Task>();

            for (int j = 0; j < userCountPerSecond; j++)
            {
                tasks.Add(CreateAndRunScenario());
            }

            _ = Task.WhenAll(tasks);
            await Task.Delay(10000); //1초
        }
    }

    // 유저 생성 후 시나리오 실행
    private static async Task CreateAndRunScenario()
    {
        int userId = Interlocked.Increment(ref userCounter);

        // SSL 인증서 무시 설정을 추가한 HttpClient 생성
        var handler = new HttpClientHandler
        {
            ServerCertificateCustomValidationCallback = (message, cert, chain, errors) => true
        };

        using (var localClient = new HttpClient(handler))
        {
            var loginToken = await ATask();

            if (!string.IsNullOrEmpty(loginToken))
            {
                log.Info($"[A Task] User {userId} signed up successfully with login token: {loginToken}");

                for (int i = 0; i < 3; i++)
                {
                    await BTask();
                    log.Info($"[B Task] User {userId} with token {loginToken} called API B.");

                    await Task.Delay(2000);

                    await CTask();
                    log.Info($"[C Task] User {userId} with token {loginToken} called API C");

                    await Task.Delay(2000);

                    await DTask();
                    log.Info($"[D Task] User {userId} with token {loginToken} called API D");

                    await Task.Delay(2000);
                }

                log.Info($"User {userId} has completed all missions and is exiting.");
            }
            else
            {
                log.Warn($"[A Task] User {userId} failed to sign up.");
            }
        }
    }


    #region API methods

    // A Task
    private static async Task<string> ATask()
    {
        // A API 호출
    }

    // B Task
    public static async Task BTask()
    {
        // B API 호출
    }

    // C Task
    public static async Task CTask()
    {
        // C API 호출
    }

    // D Task
    public static async Task DTask()
    {
        // D API 호출
    }

    #endregion
}

 

성능 테스트 과정

서버 모니터링 시스템을 킨 후 현재 CPU, Memory를 확인한 후 프로그램을 실행하였습니다.
초당 30명 생성은 약 5초 후에 CPU 100% 차면서 서버가 멈췄습니다😂
현재 개발 서버 스펙은 초당 15명 생성이 한계였습니다😂


개발 서버를 2배로 스펙업 후 초당 40명 생성을 확인 하였고

약 3시간 동작 결과 CPU 70%로 안정적으로 시나리오 동작 하는 것을 확인 하였습니다.

 

성능 테스트 완료

상용 서버와 개발 서버 스펙업을 비교 하고 유저 유입 기간에 맞춰서

상용 서버 스펙업을 진행하기로 하였습니다.


그리고 성공적으로 상용서버에서 유저 유입에 성공 하였습니다🎈 🎈 🎈

안녕하세요. 이번 포스트에서는 이미지 생성 API를 호출할 때 사용하는 세팅 값에 대해서 정리해보려고 합니다.

적절한 값을 세팅하면 좋은 결과를 얻을 수 있을 것 같습니다.

저는 black-forest-labs/flux-dev – Run with an API on Replicate 기준으로 정리해보고 있습니다.

* Image Generator(이미지 생성기)는 입력된 텍스트를 기반으로 인공지능이 이미지를 생성하는 도구입니다. 사용자는 간단한 설명이나 키워드를 입력하면, 이에 맞는 고품질 그래픽, 그림 또는 사진을 얻을 수 있습니다. 이 기술은 콘텐츠 제작, 디자인, 예술 등 다양한 분야에서 창의적인 작업을 돕습니다.

세팅값

prompt

생성하고자 하는 이미지의 주제를 설명하는 텍스트입니다. 예를 들어 "바닷가에 있는 빨간 등대"라고 입력하면 해당 주제의 이미지가 생성됩니다.

 

aspect_ratio

이미지를 생성 비율 ex. 1:1, 16:9

 

image

이미지를 생성할 때 참고할 초기 이미지를 제공합니다. 이 초기 이미지를 기반으로 텍스트와 결합하여 새로운 이미지를 만듭니다.

 

prompt_strength

초기 이미지와 텍스트 중 어떤 요소를 더 많이 반영할지를 설정합니다. 값이 높으면 텍스트가 더 많이 반영되고, 낮으면 초기 이미지가 더 강조됩니다.

 

num_outputs

한 번에 생성할 이미지의 개수를 지정합니다. 예를 들어 값을 3으로 설정하면 한 번에 3개의 이미지가 생성됩니다.

 

num_inference_steps

이미지 생성 과정에서 품질과 세부 사항을 결정하는 반복 단계 수입니다. 단계가 많을수록 이미지 품질이 높아지지만, 처리 시간이 더 길어집니다.

 

guidance

텍스트 지침을 얼마나 엄격하게 따를지를 조정하는 값입니다. 높을수록 텍스트 설명에 더 충실한 이미지가 생성됩니다.

 

seed

생성 결과를 반복적으로 동일하게 얻기 위한 랜덤 값 초기화 번호입니다. 같은 prompt와 seed를 사용하면 동일한 이미지를 생성할 수 있습니다.

 

output_format

생성된 이미지의 파일 형식을 설정합니다. 예를 들어 PNG 또는 JPEG 같은 형식을 선택할 수 있습니다.

 

output_quality

생성 이미지의 해상도와 품질을 조정하는 옵션입니다. 값이 높을수록 선명한 이미지가 만들어지지만 파일 크기가 커질 수 있습니다.

 

disable_safety_checker

안전 필터를 비활성화할지 여부를 설정합니다. 비활성화하면 특정 제한 없이 다양한 이미지가 생성될 수 있습니다.

 

go_fast

이미지 품질을 조금 낮추는 대신 생성 속도를 빠르게 하는 옵션입니다. 시간이 제한된 상황에서 유용합니다.

 

megapixels

생성 이미지의 크기(해상도)를 결정하는 값입니다. 예를 들어 1MP는 작은 크기, 5MP는 고해상도 이미지를 의미합니다.

결론

이미지 생성 API의 세팅 값은 각 항목이 이미지의 품질, 속도, 스타일에 영향을 미치므로 목적에 맞게 조정해야 합니다. 처음에는 기본 값을 사용해보고, 필요에 따라 세부 옵션을 조정하며 최적의 결과를 찾아가는 것이 중요합니다. 이러한 설정을 이해하면 원하는 이미지를 효율적으로 생성할 수 있습니다.

안녕하세요. 이번 포스트에서는 Rocky Linux 서버에서 NTP 동기화 문제를 해결하고 JWT 토큰 오류를 해결한 과정을 공유하려고 합니다. 시간 동기화 문제는 JWT 토큰 생성 및 사용 시 중요한 요소이기 때문에, NTP 동기화 설정이 제대로 되어 있지 않으면 다양한 문제가 발생할 수 있습니다.

 

* NTP(Network Time Protocol) 서버는 네트워크 상에서 시간을 정확히 맞춰주는 서버입니다. 시스템 시간의 정확한 동기화는 보안, 로그 기록, 일정한 작업 수행을 위해 중요합니다. 정확한 시간 동기화가 없으면 인증 오류, 로그 불일치 등 문제가 발생할 수 있습니다.

문제 발생

서버 로그에서 JWT 토큰 생성 시 다음과 같은 오류가 발생했습니다:

Error: "invalid_grant", Description: "Invalid JWT: Token must be a short-lived token (60 minutes) and in a reasonable timeframe"

timedatectl status 명령어를 통해 시간 동기화 상태를 확인한 결과, System clock synchronized: no로 표시되었고, NTP 서버와 동기화되지 않는 문제가 발견되었습니다.

문제 해결 과정

1. chrony 설치 및 설정

Rocky Linux에서는 chrony를 사용하여 NTP 동기화를 설정합니다.

chrony 설치

sudo yum install chrony

chrony.conf 파일 설정

/etc/chrony.conf 파일을 열어 NTP 서버 설정을 추가합니다.

sudo vi /etc/chrony.conf

 

다음과 같은 설정을 추가합니다:

# Use public servers from the pool.ntp.org project.
pool pool.ntp.org iburst
server time.google.com iburst
server time.cloudflare.com iburst
server ntp.ubuntu.com iburst

# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 second.
makestep 1.0 3

# Enable kernel synchronization of the real-time clock (RTC).
rtcsync

# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift

# Specify directory for log files.
logdir /var/log/chrony

2. chrony 서비스 재시작 및 동기화 강제 업데이트

chrony 서비스를 재시작하고 시간 동기화를 강제 업데이트합니다.

sudo systemctl restart chronyd
sudo chronyc -a makestep

3. timedatectl 상태 확인

시간 동기화 상태를 확인합니다.

 
timedatectl status

 

출력 예시:

Local time: Mon 2024-07-29 10:32:29 KST
Universal time: Mon 2024-07-29 01:32:29 UTC
RTC time: Mon 2024-07-29 01:32:29
Time zone: Asia/Seoul (KST, +0900)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

4. 방화벽 설정 확인

서버의 방화벽 설정을 확인하여 NTP 트래픽이 차단되지 않도록 설정합니다.

sudo iptables -A INPUT -p udp --dport 123 -j ACCEPT
sudo iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
sudo service iptables save

5. 수동 NTP 동기화

ntpdate를 사용하여 수동으로 NTP 서버와 동기화를 시도합니다.

sudo yum install ntpdate
sudo ntpdate pool.ntp.org

6. 시스템 재부팅

모든 설정을 완료한 후, 시스템을 재부팅하여 설정이 제대로 적용되도록 합니다.

sudo reboot

7. 최종 확인

시스템 재부팅 후, timedatectl status 명령어를 실행하여 시스템 시간 동기화 상태를 다시 확인합니다.

결론

이 단계를 통해 시스템 시간이 NTP 서버와 올바르게 동기화되었으며, JWT 토큰 생성 및 사용 시 발생하는 시간 관련 오류가 해결되었습니다. 시스템 시간이 정확하게 동기화됨으로써 시간에 민감한 작업이 정상적으로 수행될 수 있게 되었습니다.

이와 같은 문제를 해결할 때는 NTP 서버와의 시간 동기화 상태를 항상 확인하고, 필요한 경우 방화벽 설정 및 네트워크 설정을 점검하여 원활한 동기화가 이루어지도록 해야 합니다.

Mongo DB에 유저를 생성하고 권한을 부여해보겠습니다.

먼저MongoDB 쉘에 접속을 해야합니다.

 

1. Mongo Shell 설치

sudo apt-get update
sudo apt-get install -y mongodb-org-shell

 

2. Mongo Shell 실행

mongosh

 

3. 관리자 유저 생성하는 법

# admin database 진입
use admin

# admin user 생성 및 권한 부여
db.createUser({
  user: "yourUsername",
  pwd: "yourPassword",
  roles: [{ role: "userAdminAnyDatabase", db: "admin" }]
});

 

4. 개발용 유저 생성하는 법

# 관리자로 접속
mongosh -u adminUser -p adminPassword --authenticationDatabase admin

# admin database 진입
use admin

# dev user 생성
db.createUser({
  user: "myuser",
  pwd: "mypwd",
  roles: []
});

# dev user 권한 부여
db.grantRolesToUser("myuser", [
  "readWriteAnyDatabase",
  "dbAdminAnyDatabase",
  "userAdminAnyDatabase"
])

# 접속 확인
mongodb://myuser:mypwd@{mongodb설치된url:port}

AWS CloudWatch는 애플리케이션을 모니터링할 수 있도록 해주는 서비스 입니다.

 

하지만 기본적으로 CPU 사용률, 디스크 I/O, 네트워크 부하 등 기본 지표는 제공을 하나

인스턴스 메모리 및 운영체제 디스크 사용률과 같은 운영체제의 지표는 가져오지 못합니다.

이를 위해서 CloudWatch Agent를 설치하여 메모리와 디스크 사용률을 가져올 수 있는 방법을 정리해보려고 합니다.

 

Linux(Ubuntu) 운영체제에서 진행해보겠습니다.

 

1. Aws IAM 역할 만들기

 

1) IAM 접속 > 역할 > 역할 생성 > AWS 서비스 > EC2 > CloudWatchAgentServerPolicy 

역할 생성
CloudWatchAgentServerPolicy 추가

2) 원하는 EC2 인스턴스에 IAM 역할을 수정해줍니다.


2. Ubuntu CloudWatchAgent 설치

 

1) CloudWatchAgent(amazon-cloudwatch-agent) 설치 합니다.

wget https://s3.amazonaws.com/amazoncloudwatch-agent/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb
sudo dpkg -i -E ./amazon-cloudwatch-agent.deb

 

2) 마법사 파일을 실행합니다.

 sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

3) Log는 모니터링하지 않고 CPU, 메모리만 나오도록 진행합니다.

$ /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard
================================================================
= Welcome to the Amazon CloudWatch Agent Configuration Manager =
=                                                              =
= CloudWatch Agent allows you to collect metrics and logs from =
= your host and send them to CloudWatch. Additional CloudWatch =
= charges may apply.                                           =
================================================================
On which OS are you planning to use the agent?
1. linux
2. windows
3. darwin
default choice: [1]:
1
Trying to fetch the default region based on ec2 metadata...
Are you using EC2 or On-Premises hosts?
1. EC2
2. On-Premises
default choice: [1]:
1
Which user are you planning to run the agent?
1. root
2. cwagent
3. others
default choice: [1]:
2
Do you want to turn on StatsD daemon?
1. yes
2. no
default choice: [1]:
2
Do you want to monitor metrics from CollectD? WARNING: CollectD must be installed or the Agent will fail to start
1. yes
2. no
default choice: [1]:
2
Do you want to monitor any host metrics? e.g. CPU, memory, etc.
1. yes
2. no
default choice: [1]:
1
Do you want to monitor cpu metrics per core?
1. yes
2. no
default choice: [1]:
1
Do you want to add ec2 dimensions (ImageId, InstanceId, InstanceType, AutoScalingGroupName) into all of your metrics if the info is available?
1. yes
2. no
default choice: [1]:
1
Do you want to aggregate ec2 dimensions (InstanceId)?
1. yes
2. no
default choice: [1]:
1
Would you like to collect your metrics at high resolution (sub-minute resolution)? This enables sub-minute resolution for all metrics, but you can customize for specific metrics in the output json file.
1. 1s
2. 10s
3. 30s
4. 60s
default choice: [4]:
4
Which default metrics config do you want?
1. Basic
2. Standard
3. Advanced
4. None
default choice: [1]:
3
Current config as follows:
{
	"agent": {
		"metrics_collection_interval": 60,
		"run_as_user": "root"
	},
	"metrics": {
		"aggregation_dimensions": [
			[
				"InstanceId"
			]
		],
		"append_dimensions": {
			"AutoScalingGroupName": "${aws:AutoScalingGroupName}",
			"ImageId": "${aws:ImageId}",
			"InstanceId": "${aws:InstanceId}",
			"InstanceType": "${aws:InstanceType}"
		},
		"metrics_collected": {
			"cpu": {
				"measurement": [
					"cpu_usage_idle",
					"cpu_usage_iowait",
					"cpu_usage_user",
					"cpu_usage_system"
				],
				"metrics_collection_interval": 60,
				"resources": [
					"*"
				],
				"totalcpu": false
			},
			"disk": {
				"measurement": [
					"used_percent",
					"inodes_free"
				],
				"metrics_collection_interval": 60,
				"resources": [
					"*"
				]
			},
			"diskio": {
				"measurement": [
					"io_time",
					"write_bytes",
					"read_bytes",
					"writes",
					"reads"
				],
				"metrics_collection_interval": 60,
				"resources": [
					"*"
				]
			},
			"mem": {
				"measurement": [
					"mem_used_percent"
				],
				"metrics_collection_interval": 60
			},
			"netstat": {
				"measurement": [
					"tcp_established",
					"tcp_time_wait"
				],
				"metrics_collection_interval": 60
			},
			"swap": {
				"measurement": [
					"swap_used_percent"
				],
				"metrics_collection_interval": 60
			}
		}
	}
}
Are you satisfied with the above config? Note: it can be manually customized after the wizard completes to add additional items.
1. yes
2. no
default choice: [1]:
1
Do you have any existing CloudWatch Log Agent (http://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AgentReference.html) configuration file to import for migration?
1. yes
2. no
default choice: [2]:
2
Do you want to monitor any log files?
1. yes
2. no
default choice: [1]:
2

Saved config file to /opt/aws/amazon-cloudwatch-agent/bin/config.json successfully.
Current config as follows:
{
	"agent": {
		"metrics_collection_interval": 60,
		"run_as_user": "root"
	},
	"logs": {
		"logs_collected": {
			"files": {
				"collect_list": [
					{
						"file_path": "/var/log/nginx/access.log",
						"log_group_name": "access.log",
						"log_stream_name": "{instance_id}",
						"retention_in_days": -1
					}
				]
			}
		}
	},
	"metrics": {
		"aggregation_dimensions": [
			[
				"InstanceId"
			]
		],
		"append_dimensions": {
			"AutoScalingGroupName": "${aws:AutoScalingGroupName}",
			"ImageId": "${aws:ImageId}",
			"InstanceId": "${aws:InstanceId}",
			"InstanceType": "${aws:InstanceType}"
		},
		"metrics_collected": {
			"cpu": {
				"measurement": [
					"cpu_usage_idle",
					"cpu_usage_iowait",
					"cpu_usage_user",
					"cpu_usage_system"
				],
				"metrics_collection_interval": 60,
				"resources": [
					"*"
				],
				"totalcpu": false
			},
			"disk": {
				"measurement": [
					"used_percent",
					"inodes_free"
				],
				"metrics_collection_interval": 60,
				"resources": [
					"*"
				]
			},
			"diskio": {
				"measurement": [
					"io_time",
					"write_bytes",
					"read_bytes",
					"writes",
					"reads"
				],
				"metrics_collection_interval": 60,
				"resources": [
					"*"
				]
			},
			"mem": {
				"measurement": [
					"mem_used_percent"
				],
				"metrics_collection_interval": 60
			},
			"netstat": {
				"measurement": [
					"tcp_established",
					"tcp_time_wait"
				],
				"metrics_collection_interval": 60
			},
			"swap": {
				"measurement": [
					"swap_used_percent"
				],
				"metrics_collection_interval": 60
			}
		}
	}
}
Please check the above content of the config.
The config file is also located at /opt/aws/amazon-cloudwatch-agent/bin/config.json.
Edit it manually if needed.
Do you want to store the config in the SSM parameter store?
1. yes
2. no
default choice: [1]:
2
Program exits now.

 

4) 마법사로 만들어진 json 파일 호출합니다.

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json

5) Agent를 실행시켜주세요.

# 서비스 실행
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a start

# 서비스 실행 확인
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a status
more /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log

 

6) CloudWatch > 모든 지표 정상동작 확인

정상 동작 확인

감사합니다.😊

mariadb를 실행하려고 명령어를 쳤는데

sudo systemctl start mariadb

 

 mariadb.service: Main process exited, code=exited, status=1/FAILURE
 mariadb.service: Failed with result 'exit-code'.
 Failed to start MariaDB 10.6.12 database server.

오류가 발생했습니다. 

이를 해결할 수 있는 방법을 알아봤는데 생각보다 간단한 방법이 있었습니다.

 

# 패키지를 재구성하고 패키지 자체의 설정을 변경
sudo dpkg-reconfigure mariadb-server-10.6

# 재시작
sudo systemctl restart mariadb

성공 : >

 

Aws Container를 사용하기 위해 Aws Linux Ubuntu 서버에서 aws cli 설치하는 법을 알아보겠습니다.

# Aws cli가 시스템에 설치되어 있는지 확인 후 설치
sudo apt update
sudo apt install awscli

# Aws cli 버전 확인
aws --version

# Aws Configure 설정
aws configure
secret Access Key = {}
access key = {}
Default region name = {}

 

Aws Ec2로 만들어진 Ubuntu 서버에 Docker 설치하는 법을 알아보겠습니다.

1. Docker 설치 명령어

# 패키지 업데이트
sudo apt update

# https관련 패키지 설치
sudo apt install apt-transport-https ca-certificates curl software-properties-common

# docker repository 접근을 위한 gpg 키 설정
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

# docker repository 등록
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu focal stable"

# 업데이트
sudo apt update

# 도커 설치
sudo apt install docker-ce

# 설치 확인
docker --version

2. sudo 없이 Docker 명령어 사용

# 현재 사용자를 docker group 포함
sudo usermod -aG docker ${USER}

# 터미널 재시작 후 결과 확인
id -nG

'Server > Docker' 카테고리의 다른 글

[Centos] aws linux centos에 docker로 jenkins 띄우기  (0) 2023.08.08
.net core React docker image 만드는 법  (0) 2023.04.03
Docker 명령어  (0) 2023.01.29
Docker 설치 - linux편  (0) 2023.01.29
Docker 설치 - windows편  (0) 2023.01.29

AWS Ubuntu ec2 서버에 드라이브를 추가 세팅하는 방법을 알아보겠습니다.

AWS EBS Volumn을 추가하는 방법입니다.

 

1. EBS 볼륨 생성

륨 생성을 클릭 해줍니다.

연결 시킬 인스턴스 가용 영역을 선택해주세요.

2. 인스턴스 연결

볼륨 상태가 사용 가능으로 변하면 원하는 인스턴스에 볼륨 연결을 해줍니다.
EC2 > 스토리지에서 연결이 확인 되면
인스턴스 재부팅을 진행해주세요.

3. EBS 볼륨 연결 확인하기

$ lsblk # 파일 시스템 조회

lsblk 명령어로 새로 추가된 ebs 볼륨을 확인합니다.
Linux 커널로 인해 디바이스 이름이 변경이 될 수 있습니다.

4. EBS 볼륨을 파일시스탬 포맷하기

/dev/nvme0n1은 디렉토리가 아니여서 파일 시스템으로 포맷을 해주어야 쓸 수 있습니다.

$ sudo mkfs -t ext4 nvme0n1


5. EBS 볼륨 마운트 설정하기

마운트 작업이란 운영체제에 파일 시스템을 연결하는 것입니다.

(윈도우 E: 드라이브 처럼)

$ mkdir /backup
$ mount /dev/nvme0n1 /backup

centos 서버 자체에 jenkins 설치 하는 방법에 이어 docker로 jenkins를 띄우는 방법에 대해서 알아보겠습니다.

 

1. EC2 인스터스 시작 및 설정

1) 보안 그룹 설정 시 테스트를 위해 로컬 ip에 8080(기본 Jenkins 포트) 22(SSH)를 열어 둡니다.

2. EC2 인스턴스 연결

1) SSH로 인스턴스 연결

3. Docker 설치

sudo yum update -y
sudo yum install -y docker
sudo service docker start
sudo usermod -a -G docker ec2-user

4. Jenkins Docker 이미지 실행

docker run -d -p 8080:8080 -p 50000:50000 --restart=always jenkins/jenkins:lts

5. Jenkins 초기 설정

docker exec [컨테이너 ID] cat /var/jenkins_home/secrets/initialAdminPassword

6. Jenkins 접속 확인

http://[EC2 인스턴스의 퍼블릭 IP]:8080

'Server > Docker' 카테고리의 다른 글

[Ubuntu] Docker 설치하기  (0) 2023.10.23
.net core React docker image 만드는 법  (0) 2023.04.03
Docker 명령어  (0) 2023.01.29
Docker 설치 - linux편  (0) 2023.01.29
Docker 설치 - windows편  (0) 2023.01.29

+ Recent posts