2편 Wazuh 에이전트 등록

1편과 2편에서 Wazuh 자체에 대해서 알아봤다. 나도 원래는 Wazuh 하나만 사용할 생각이었는데, 네트워크 모니터링을 추가해야 할 일이 생겨서 suricata를 사용하게 되었다.

Suricata란?

Suricata Suricata-docker

Github에 나와있는 설명에 따르면 다음과 같다

Suricata는 OISF와 Suricata 커뮤니티에서 개발한 네트워크 침입 탐지 시스템, 침입 방지 시스템 및 네트워크 보안 모니터링 엔진입니다.

말그대로 네트워크 모니터링이다. 기본적으로 네트워크 패킷에 대한 분석이 가능하며, 이를 eve.json 에 넣어주는데, 알람이나 대시보드 기능은 없다. 따라서 ELK Stack으로 직접 구현하거나, 나처럼 Wazuh를 함께 도입하여 확인해야 하는 것

나는 기존에 테스트하고 있던 Wazuh에 고대로 올려서 확인했다.

Wazuh + Suricata 도입 시 해야할 일

일단 Wazuh Container 3개 (Wazuh-dashboard , Wazuh-indexer , Wazuh-manager)가 있는 상황에서부터 시작한다.

해야할 일은 크게 3가지이다.

1. Suricata 설치 및 기본 룰 세팅
2. Wazuh에서 eve.json을 읽을 수 있도록 설정
3. 제대로 수집되고 있는지 확인할 것

순서대로 진행해보겠다.

1. Suricata 설치 및 기본 룰 세팅

Suricata git clone을 하면 되는데, 그럼 소스로 받아야한다. Wazuh는 소스 내에 Dockerfile이 있어서 수월하게 했는데, 얘는 없음 ㅜ 그래서 찾아보니 Suricata-docker 레포를 만들어주신 게 있어서 갖다가 썼다!

Suricata-docker

이렇게 하면 커스터마이징이 어렵다는 단점이 있는데, 어차피 우리는 가볍게 룰셋 정도만 변경해서 사용할 것이기 때문에, 별 문제는 없다고 판단해서 편하게 가져다가 썼다~

README를 읽으면 실행 방법까지 자세하게 설명해 준다.

ip -br addr

명령어를 사용하면 내 인터페이스를 찾을 수 있다. 인터페이스를 추가해서 돌리면 됨!

docker run -it -d --net=host \
    --cap-add=net_admin --cap-add=net_raw --cap-add=sys_nice \
    jasonish/suricata:latest -i <interface>

💡 여기서 잠깐! 난 여기서 하나 더 해야된다. 바로 룰셋 지정.. 어떤 룰이 들어와서 detect 되었을 때 중요 이슈로 판단할 것인가에 대한 룰셋을 지정해줘야 한다.

먼저, 도커 이미지에 올라갈 룰셋을 지정해준다. 그러려면 당연히 설정 파일이 있어야하고, 설정 파일은 다음과 같이 이미지에서 뽑을(?) 수 있다.

sudo docker run --rm \
  -v "$(pwd)/suricata/settings:/etc/suricata" \
  -v "$(pwd)/suricata/var/lib/suricata:/var/lib/suricata" \
  jasonish/suricata:latest sh -c "suricata-update update-sources && suricata-update enable-source et/open && suricata-update"

일단 한번 실행해준다. 로컬 볼륨이랑, 컨테이너 안에 있는 볼륨을 맞춰주고,

suricata-update 명령어를 통해서 기본 룰셋 (여기서는 ET라고 부르더라) 을 가져와준다. 지피티 괴롭혀서 알아봤는데 기본적으로 보안 업계에서 "크리티컬하다"라고 말하는 룰셋은 들어가 있다고 한다. 난 보안을 잘 모르니까 주는대로 써야한다. 기본적인 보안이라도 지키려면.... 그렇게해서 리스타트 하고 나면, 로컬 볼륨에 기본 룰셋들이 들어와 있는 걸 볼 수 있다.

여기서 내가 겪은 문제 ! 그냥 짜잔 하고 되면 너무 좋은데, Suricata가 기본적으로 수접하는 것들이 너무 많고, 너무 길어서 Wazuh가 max length를 넘어서 읽어버리게 된다. 그럼 이러한 에러가 나온다 ,, ㅠㅠ 2026/03/23 02:20:38 wazuh-analysisd: ERROR: Too many fields for JSON decoder. 그러니까 우리는 max length를 조절하거나, Suricata의 로그 레벨을 조정해 주어야 한다. (정확히는 레벨은 아니고 종류?)

Suricata가 수집하는 것들

• alert
• flow
• dns
• http
• tls
• stats

alert flow ssh 를 제외하면, 나머지는 크게 의미가 없다고 한다. 딥하게 수집/분석하고 싶으면 다 써도 되겠지만, 나는 어떤 트래픽이 크리티컬한지, 공격 시도가 있었는지 정도 보고 싶은 거라 위의 세개만 켜주었다.

이걸 수정하기 위해서는 로컬 마운트된 곳에서 suricata.yaml 파일을 찾아 주는데, 찾고 나면 뭐가 엄청 길어서 찾고 설정하기가 쉽지 않다.

이 부분은 AI한테 적당히 물어봐서 자동으로 수정해 주는 걸 쓰도록 하자.

그리고 나서 다시 한번 container를 실행시키면, 룰이 잘 지정되어 있고, 우리가 지정된 룰을 확인할 수 있다.

sudo docker run -d \
  --name suricata \
  --net=host \
  --cap-add=NET_ADMIN \
  --cap-add=NET_RAW \
  --cap-add=SYS_NICE \
  -v "$(pwd)/suricata-logs:/var/log/suricata" \
  -v "$(pwd)/suricata/settings:/etc/suricata" \
  -v "$(pwd)/suricata/var/lib/suricata:/var/lib/suricata" \
  jasonish/suricata:latest \
  -i enp6s0

내가 올린 룰이 ls -la ~/suricata/var/lib/suricata/rules/suricata.rules 이렇게 해서 보면, 디렉토리에 잘 들어와 있을 것이다.

그럼 Suricata 기본 설정은 끝이다.

2. Wazuh에서 Suricata를 읽을 수 있도록 설정

여기서는 어렵지 않다.

Wazuh-docker 루트로 가면, single-node가 있다. 우린 그걸로 올렸으니 거기 docker-compose.yml 파일을 수정해주면 된다.

가서 보면 볼륨이 이렇게 잡혀 있을 건데,

volumes:
  - ./config/wazuh-agent-conf:/wazuh-config-mount/etc/ossec.conf

이걸 아래처럼 하나 추가해주면 된다.

volumes:
  - ./config/wazuh-agent-conf:/var/ossec/etc/ossec.conf
  - ~/suricata-logs:/var/log/suricata

그냥 suricata의 로그들을 여기로 끌고오겠다는거니까 문제 놉

그리고 호스트 파일을 수정해서 몇줄 추가해준다.

vi ~/wazuh-docker/wazuh-agent/config/wazuh-agent-conf

<ossec_config>
  ...

  <localfile>
    <log_format>json</log_format>
    <location>/var/log/suricata/eve.json</location>
  </localfile>

</ossec_config>

ossec_config 제일 하단에 샥

그러고 나서 리스타트

cd ~/wazuh-docker/wazuh-agent
docker compose down
docker compose up -d

확인하고자 한다면,

docker exec -it wazuh.agent ls -l /var/log/suricata
tail -f ~/suricata-logs/eve.json

이런식으로 그냥 로그 들어오는지 찍어서 확인해보자.

문제가 없다면 eve.json 연동은 마무리~!

3. 확인하기

Wazuh dashboard로 가서 이벤트를 확인하면

이렇게 rule.groups에 suricata로 들어와 있다.

이렇게 하면 어느정도 돌아가는 걸 확인할 수 있다는 사실!

다음번에는 슬랙으로 알람 추가하는 걸 해봅시다~!

이전에 성공적으로 Wazuh 서비스 설치를 했다면, 이번에는 데이터를 수집할 서버에 수집기를 설치해야한다.

수집하고 싶은 서버에 설치를 하는 건 상당히 간단하다.

일단 Agents Summary로 들어간다.

Deploy new agent로 들어가면 어떻게 설치할 수 있는지, OS 선택 및 Options를 선택할 수 있다.

설치하고 싶은 OS를 고르고, 설치한 서버 주소를 입력해주면 된다. Agent Name은 보여질 이름이기에 편한 이름으로 입력하고 나면

이런식으로 설치하라고 한다.

정상적으로 설치하고 나면, 수집은 금방 되기 때문에.. 별 문제가 없다!

이렇게 해서 Wazuh 설치 및 사용법을 알았으면, 이제 좀 더 어려운 걸로 가보자!

다음에는, Suricata 와 연동해서 Wazuh에 이슈를 구현하는 방법을 알아볼 것이다.

우리는 거의 모놀리식에 가까운 구조라서 여러 대의 서버를 동시에 컨트롤 할 일은 없지만 (시뮬레이터 제외) 이렇게 여러 대의 테스트 인스턴스를 한번에 띄워보기란 스타트업에서 경험하기 힘들다고 생각한다.

일단 Terraform만 사용해도 괜찮았을거라는 사수분의 이야기가 있었으나, 난 진짜 해보고 싶은 거라 Ansible을 같이 썼다

Terraform은 진짜 서버만 올리는 용도라서 Ansible만 일단 적어보도록 하자

대충 구조는 이러하다

ansible.cfg 이거는 ansible에서 필요한 기본 설정 파일이다 hosts.ini 이거는 컨트롤해야하는 여러 대의 서버에 대한 정보를 담았다. Terraform에서 추출된 여러 대의 서버의 ip와 정보를 여기에 적어주는 스크립트가 필요하다. group.yml 여러 변수들을 담았다. {{ }} < 이 문법을 사용해서 변수 가져온다 playbooks 우리가 잘 알고있는 플레이북이다.

• 일단 AI 쓰면 내꺼가 안될거같아서 처음에 setup 만 혼자 작성하고 나머지는 AI 뚝딱했다 claude code 미친놈이다

구조만 이해하고 나면 만드는 건 어렵지 않다.

cloudwatch agent를 설치하는 플레이북을 예시로 보자

일단, 인덴트를 이용해서 다음과 같이 스텝별로 작업을 작성해준다. 요즘 이건 AI 안쓰면 안될 것 같다. 노가다를 줄여서 생산성을 n배 향상시켜주니까

그래도 스텝별로 어떤 작업이 들어가는지 한번 체크하고 영향도도 생각하자

어느 정도 스텝이 작성되었으면

ansible-playbook playbooks/setup.yml \
  -i inventory/hosts.ini \
  --check

이렇게 해서 한번 체크해준다.

그리고 나서 냅다 돌리면 끝

ansible-playbook playbooks/setup.yml \
  -i inventory/hosts.ini

근데 이러면 드는 의문이 있다. EC2에 작업했는데 왜 pem키 없지?

우리는 SSM을 사용하기 때문이다. 서버에 SSM만 올라가 있다면

# session-manager-plugin 설치
brew install --cask session-manager-plugin

# 설치 확인
session-manager-plugin --version

일단 로컬에서 컨트롤하니까 로컬에다가 ssm plugin 설치를 한다. 그 다음에 aws configure를 해주고, hosts.ini에다가 ssm으로 접근할때처럼 명령어 얍

ansible_ssh_common_args='-o StrictHostKeyChecking=no -o ProxyCommand="aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters portNumber=%p --region us-east-1"'

일단 클라우드가 아니어야 하고, (데이터 보안 문제) 그 나라 것이 아니어야 하고,, (많은 보안 문제)

아무튼 여러모로 알아보다가 미국꺼라는 Wazuh를 이용해보게 되었음. SIEM이 가능한 무료 오픈소스가 많이 없는듯했다.

1. Docker

일단 환경의 편리성을 위해서 Docker로 다운받기로 했다. Wazuh는 docker와 일반 소스코드 레포가 아주 잘 나뉘어져 있다.

참고로, 나는 main 브랜치를 별 생각 없이 깔았다가 피를 보고 다시 version을 맞추어 체크아웃했다.

다들 이런 이슈가 있지 않기를 바란다...

1. wazuh

document: https://documentation.wazuh.com/current/getting-started/index.html

이거는 그냥 일반 소스코드이다. 수정/커스텀이 필요하다면 이거 가져다 쓰면 된다.

난 귀찮아서 미리 나온 docker 이미지를 그냥 냅다 썼다.

2. wazuh-docker

document: https://documentation.wazuh.com/current/deployment-options/docker/wazuh-container.html#prerequisites

Releases 중에서 v4.14.3의 commit id를 지정해서 하면 문제없이 설치된다.

2. Dashboard 실행

순서는 다음과 같다.

1. wazuh-docker 레포 클론

   git clone https://github.com/wazuh/wazuh-docker.git

당연히 이렇게 하면 main 뜬다. 현재 latest stable 버전은 태그 v4.14.3이므로 태그 기준으로 checkout 해준다. 아니면 -b v4.14.3 을 붙여서 클론해줘도 된다.

git checkout v4.14.3

그 다음에 single-node로 이동해준다. 나의 경우 서버 몇대 안돼서 그냥 single-node로 했는데 클러스터 구성이라면 multi-node로 하면 될듯하다.

2. key generate

   docker compose -f generate-indexer-certs.yml run --rm generator

3. docker compose up

   docker compose up -d 

AI가 멍청해서 key generate 하는걸 한참 찾았다.

만약 나처럼 main 브랜치로 최신 버전 하려다가 실패했다면 설정해줘야 하는 것이 있다. (ref 참고)

ref: https://github.com/wazuh/wazuh-documentation/issues/7619

keygen해서 wazuh_indexer_ssl_certs 폴더에 담아주는데 이걸 아무리 날리고 볼륨을 refresh/delete 해도 안됐던 것.

결국 여기서 알려주는 방법대로 수동으로 파일을 삭제해주니 잘 됐다.

• 그리고 Wazuh 버전이 다양해서 그런가 인터넷에 아주 많은 낚임성 글이 있나보다.. AI가 잘 안알랴줌 document 직접 하나하나 보고 따라하는 거 추천

일단 key를 generate하고 docker compose up -d를 하면 도커 세개가 잘 뜬다.

그리고 localhost (443)으로 하면 Dashboard 로그인하라고 함.

AI는 Perplexity, Cursor, GPT 전부 다 admin, admin 하라고 하는데, 도큐먼트는

이렇게 하라고 한다. (나처럼 낭패보지 않길 바란다.)

그럼 일단 Dashboard 잘 뜬다.

자, 그럼 이제 수집하고 싶은 서버에 에이전트를 설치해보자. 이건 2탄으로 ~!

이직해서 하는 일도 (얼추 비슷한가?) 좀 바뀌어가지고, 이제 매일 매일 AWS랑 전쟁중이다.

AWS도 보면 그냥 국내 클라우드 호스팅 업체 별반 다를게 있을까 (..) 싶을 정도로 안정적이지 못한 경우가 종종 있는 것 같다. 혹은 내가 아직 에러 소명을 못했겠지 ....

아무튼 한줄 적어본다.

AWS는 기본 모니터링에 Memory 수집 지표(metrics)가 없다. 따라서 Memory를 수집하고 싶다면 직접 config를 만들어서 추가해줘야 한다.

일단, OS에 따라 다르다.

Amazon Linux를 이용하는 경우, amazon-cloudwatch-agent 가 이미 있을 것이다. 근데, Ubuntu를 사용하는 경우, 아마 없을 것이다.

Ubuntu의 경우 install이 쉽게 되지 않아서 (..) 좀 귀찮다.

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

sudo dpkg -i amazon-cloudwatch-agent.deb

우분투용 패키지를 받아서 디패키징 해준다.

amazon-cloudwatch-agent-ctl -a status

그럼 이제 amazon-cloudwatch-agent-ctl을 사용할 수 있게 된다.

cd /opt/aws/amazon-cloudwatch-agent/etc/

/opt/aws/amazon-cloudwatch-agent/etc 의 경로로 이동 !

만약 amazon-cloudwatch-agent 경로가 없는 경우 문제가 있는 것이므로 부디 다시 설치를 하기를 바란다. (확실하진 않고 경험상 그랬어요)

이제 여기다가 config.json 을 만들어 줄 것이다. 경로나, config의 이름은 자유롭게 해도 상관없다. 어차피 커맨드로 잡아줄거라서

나의 경우 gunicorn의 memory usage를 보고 싶었던 거라서, config를 다음과 같이 잡아줬다.

{
  "metrics": {
    "metrics_collected": {
      "procstat": [
        {
          "pattern": "gunicorn",
          "alias": "gunicorn",
          "measurement": [
            "cpu_usage",
            "cpu_time",
            "cpu_time_system",
            "memory_rss",
            "num_fds",
            "num_threads",
            "write_count"
          ],
          "metrics_collection_interval": 60
        }
      ],
      "mem": {
        "measurement": [
          "used_percent", "available", "total"
        ],
        "metrics_collection_interval": 60
      }
    }
  }
}

대충 ~~ 지표들을 수집할거고, gunicorn이라는 이름이 들어간 프로세스의 지표를 수집하게 해줘, 라는 의미라고 한다.

이거는 직접 찾는 것보다 chatgpt가 더 잘해줄 것입니다. 한번 찾아보시길 바랍니다!

이제 이걸 적용해주면 끝이다

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

아시겠지만 -c의 옵션 위치에 나의 설정 파일을 지정해주면 된다.

뭐시기 뭐시기하여 validation success가 뜨면 끝이다-

이제 Dashboard나 지표 수집기 쪽에 가서 데이터를 확인해보자.

아마도 CWAgent의 어딘가에 있을 것이다.

나의 경우 host 안에 있었다.

사실 실제로 config 잡고 수집하는 것보다, 여기서 찾는 게 더 시간이 오래 걸린다.

중분류 (?)가 분기가 많이 되어 있으니 CWAgent 쪽에서 꼼꼼히 ip 대조해보면서 찾아보길 바란다.

이렇게 하면 메모리 수집 끝-!

기존에는 서버에서 attachments/ 로 저장하던 파일들을.. ec2 디스크 문제로 몇번 터진 이후 개인적으로 꼭 S3로 옮기고 말겠다는 생각을 했는데, 이번에 마이그레이션 진행하면서 그냥 작업해버렸다.

꼭 내가 이 회사 안있더라도, 다른 사람들이 attachments/ 로 고통받을 걸 잘 알기에... 그냥 바로 작업 시작해버림

CI4에서 접근할 유저 만들어주기

IAM 계정을 하나 만들어줘야 한다. ci4가 접근할.. 생성은 plain하게 진행하고, 생성된 후에 액세스 키를 만들어줘야 한다.

오른쪽 상단의 액세스 키 만들기를 선택해준다.

액세스 키 모범 사례 및 대안에서는 서드 파티 서비스를 선택해준다. 그리고 나온 두개의 액세스 키를 잘 보관한다.

CI4 환경변수 or Config or Libarary를 이용해 S3 연동

<?php

namespace Config;

use CodeIgniter\Config\BaseConfig;

class S3 extends BaseConfig
{
    public string $bucketName;
    public string $region;
    public string $accessKey;
    public string $secretKey;
    public string $uploadFolder;

    public function __construct()
    {
        $this->bucketName = getenv('AWS_S3_BUCKET')?? "image-ci4";
        $this->region = getenv('AWS_REGION')?? "ap-northeast-2";
        $this->accessKey = getenv('AWS_ACCESS_KEY')?? "-----------------";
        $this->secretKey = getenv('AWS_SECRET_KEY')?? "---------------------";
        $this->uploadFolder = getenv('AWS_UPLOAD_FOLDER') ?? 'images/';
    }
}

이런식으로 config에 선언해주던가, .env에

환경변수로 선언하던가... 아니면 그냥 S3uploader 파일쪽에 선언해도 상관없다. 아무튼 들어가있으면 됨.

근데 보안적인 측면에서 셋 다 별로고 AWS측에서 제공하는 보안 키 .. 관련된 뭐시기가 있다했느데 그걸 쓰면 더 좋을듯하다.

S3Uploader Library 만들기

<?php

namespace App\Libraries;

use Aws\S3\S3Client;
use Config\S3;

class S3Uploader
{
    private $s3;
    private $bucket;
    private $uploadFolder;

    public function __construct()
    {
        $config = new S3();

        $this->s3 = new S3Client([
            'version'     => 'latest',
            'region'      => 'ap-northeast-2',
            'credentials' => [
                'key'    => "",
                'secret' => ""
            ],
        ]);

        $this->bucket = $config->bucketName;
        $this->uploadFolder = $config->uploadFolder;
    }

    public function uploadFile($file)
    {
        $sFileName = $file->getRandomName();

        try {
            $this->s3->putObject([
                'Bucket' => $this->bucket,
                'Key'    => $sFileName,
                'Body'   => fopen($file->getTempName(), 'rb'),
                'ContentType' => $file->getMimeType()
            ]);

            return "https://{$this->bucket}.s3.{$this->s3->getRegion()}.amazonaws.com/{$sFileName}";

        } catch (\Exception $e) {
            return $e->getMessage();
        }
    }
}

여러모로 중구난방인데 아무튼 , config에서 bucketName 불러오듯 key 값도 불러오면 된다 .. (난 한 1시간정도밖에 없어서.. 후딱 만드느라 막 함 추후 수정해야지)

위의 코드를 보면, return 값으로 url을 주고 있음. 이걸 RDB에 저장하고, RDB에서는 이 값을 이용해 이미지를 호출하게 됨.

컨트롤러에서 호출 and RDB에 저장

$aImages = $this->request->getFileMultiple('document_images');
        $oS3 = new S3Uploader();

foreach($aImages as $oImage){
            if($oImage->isValid() && !$oImage->hasMoved()){
                $sUrl = $oS3->uploadFile($oImage);

                if ($sUrl) {
                    $aUpload[] = $sUrl;
                    // DB 적재
                    $aData = [
                        //"title" => $oImage->getName(),
                        "box_idx" => $iBox,
                        "file_path" => $sUrl
                    ];
                    if($this->oMypage->insertBox($aData)){
                        $aSuccess[] = $sUrl; 
                    }else {
                        $aFailure[] = $sUrl;
                    }
                } else {
                    $aFailure[] = $sUrl;
                }
            }
        }

난 로그 쌓을거라 이렇게 Failure 등 따로 append 했다!!!

연동할 때 고민해줘야 하는 부분이 있는데, 바로 어디까지 public으로 접근 가능하게 할 지에 대한 부분이다. S3 자체를 public 으로 하는 방법도 있지만 절-대 추천하지 않고, 나는 일부 소스 (일부 경로)에 대해서만 public 권한을 주고 나머지는 private으로 유지하는 방법을 선택했다.

Library 코드에는 나와있지 않지만 경로가 설정되어 있고, 해당 경로로 public 권한을 open해주는 설정을 json으로 선택할 수 있다.

버킷 권한

버킷 권한의 버킷 정책이다.

여기에서 특정 경로의 public 권한 관련된 내용은 찾아보기를..

일단 JWT 토큰을 이용해 로그인 체크를 구현해보았다.

php-jwt 설치

먼저 Codeigniter의 루트 패스로 가서

composer require firebase/php-jwt

를 실행해서 php-jwt를 설치해준다.

이렇게 설치를 하면 vender 하위에 firebase/php-jwt가 생기게 된다.

생긴걸 확인 후 Helper 함수를 만들어준다.

Helper 함수는 Controller 내 어디서든 helper(' ')를 통해 클래스를 참조할 수 있게 도와준다.

.env에 jwt 토큰 키 추가

토큰 키를 어렵게 만들어서 한줄 추가한다.

.env는 굳이 다른걸 건드리지 않아도 자동반영되지만, 나는 캐시 삭제를 해주었다.

Helper 파일 생성

참고로 helper 파일은 xxx_helper로 만들어야한다. 꼭 언더바 helper가 들어가야 한다는 것...

이건 지쌤이 짜준거 고친거당 지쌤 편해,,,,, 이런걸 왜 이제 알았을까나

Controller 수정

이제 컨트롤러에서 이렇게 helper로 jwt를 불러서 토큰을 만든담에 세션에 담아준다.

Filter 수정

app/Filters/auth.php 필터를 만들어서 token이 없으면 팅겨내는 코드를 추가한다.

그리고 필터에 삽입!

참고로 현재는 프론트팀원들이 돌아다니면서 작업중이라 주석처리해놨다 ㅎㅎ

크기를 올리기만 하면 되는 줄 알았는데... 실제로 서버에서 df -h 찍으니까 안잡히더라구요 ... 또륵

지쌤한테 물어보니, AWS에서 EBS 볼륨 크리를 올려도 OS가 자동으로 확장된 공간을 인식하지 못하는 이유는, 파일 시스템과 파티션이 존재하기 때문이라고 합니다.

EBS는 단순한 물리적인 공간일 뿐이고, 이를 사용하기 위해서는 운영체제에서 파티션을 인식하고 파일시스템을 확장하는 작업이 필요하다고 하네여 ㅠ

즉, 물리적인 공간을 올렸지만 OS는 파티션에 의해 원래의 6GB 정도만 자기꺼라고 인식하고 있으니, 물리적인 공간을 크게 키운 다음, 파티션을 키워줘야 OS가 사용할 수 있는 공간이 늘어남.

나의 경우, 파티션이 있고 ext였기에,

해당 명령어를 통해 파티션 크기를 늘려주고, 파일시스템의 크기를 늘려주었다.

그래서 파일시스템이 뭔데? ㅠㅠ

파일시스템은 데이터를 관리하는 방식인데, 파티션 크기가 커진다고 해서 관리하는 방식 (두뇌) 가 커진걸 인지하지 못하는 상태이므로, 파일시스템한테 야, 너 커졌음 여기까지 써도 OK라고 알려주는 정도로 이해하면 될 것 같다.

일은 해봐야 알겠지만 django, celery, python을 사용하는 회사로 이직하고자 하였습니다. php 개발자로 입사했더니 python으로 돌아오는 길이 멀고도 험했네요

CS질문은 거의 대답을 못했습니다... 한 3년을 계속 실무만 보고 달려오니 많이 까먹었더라고요.. (특히 python은 거의 다...) 그래도 제 개념 속에서 아는 내용을 모두 답했는데, 그걸 좋게 봐주신 듯 합니다.

그런데 공부는 많이 해야겠네요 특히 이론공부 ㅠㅠ

1. DB 관련 질문

• index searching의 종류를 아는가
• 샤딩과 파티셔닝
• Django와 mysql을 함께 사용한 이유는 무엇인가 (Django의 권장사항은 PostgresQL이라고 합니다)
• 분산DB CAP의 개념

2. 알고리즘

• DFS, BFS
• 길찾기 알고리즘
• Deque와 Stack과 Queue

3. 인프라

• Docker compose와 k8s

4. 네트워크

• https와 http의 차이 (아 이건 공개키 이야기를 했어야하는데...단어가 ㅠ)
• TCP Three handshake

그리고는 기억이 잘 안납니다... 너무 긴장했나봐...

이 외에는 한 40분정도 제 개인 프로젝트에 대해서 이야기 나눈 것 같아요. 사실 많이 아는 건 없는데, 프로젝트할 때 제가 어떤 생각으로 몇가지 안중에 이것을 선택했는가에 대해 많이 이야기했습니다.

레거시를 어떻게 없앨 것인가에 대해서는 직접 해서 보여드리는 편이라고 말씀 드렸구요... (실제로 그렇게 함)

제가 이론 대답을 너무 못하니 쉬운 문제를 물어봐주셨는데도 대답못했습니다... 난 바보야

다만, 대답을 안한 건 아니고 제가 아는 선에서.. 예를 들어 hash 와 b-tree 는.. 아마.. 이랬던 거 같다. (경험을 말하며) 이렇게 대답했고, b-tree 관련해서는 ElasticSearch LIKE 쿼리에서 본 내용들을 토대로, 이런 개념인 것을 이해한다. 라고 말씀드렸어요

마지막 질문이 "그럼 비전공자셔서 공부는 어떻게 하셨어요?" 여서, 쉴틈없이 현업에 있었기 때문에 이론은 잘 모를지 몰라도 배우는거나 경험으로 알게 된 내용들은 대부분 기억한다. 라고 답변드렸던 기억이 납니다....

그리고 반대로 저한테 CAP의 개념 등을 알려주시기도 하셨는데, 새로운 걸 알아서 되게 좋았어요 ㅎㅎ

• 준비되어 있어야 할 것 : 카카오 개발자 아이디와 활용신청 (biz의 경우 검수까지 며칠 걸림)

카카오 입장에서는 생판 모르는 사람에게 누군가의 정보를 줄 수는 없는 노릇이라, 나름 개인정보를 어디에 쓸건지? 너네 진짜 서비스하는 앱이 맞는지? 등을 확인하는 과정이 있다. 이 과정을 모두 거치고 kakao biz 딱지를 얻으면, 개발이 가능하게 된다.

만약 biz 딱지를 얻지 못했다면, 닉네임과 프로필 사진 정도 등의 정보에 대해서만 권한을 획득할 수 있다. 근데 어차피 카카오측에서 엄청 긴 string을 주는데 그게 nice의 개인식별코드..? 같은 느낌이다. 그래서 인간 구별은 가능함. auth id만 얻어와서 그걸로 다시 우리측 앱이나 서비스에서 가입시키면 (이름과 번호를 받으면) 굳이 biz 딱지를 얻지 않아도 된다. 카카오로 다시 로그인할때 어떤 일이 생길지는.. 일단 지켜봐야한다.

1. Kakao Developers 앱설정에서 카카오 로그인 ON으로 변경하기

활성화 설정을 ON으로 바꾸고 Redirect URI 를 넣어준다. 말 그대로 카카오측에서 이 사람 얘야 라고 알려줄 URI를 뜻한다. 나의 경우 백단 처리가 필요해서 (db에 auth id 담아야하니까) PHP 파일로 리다이렉트 시켰다.

2. js 구현

이제 버튼을 누르면 진행될 함수를 넣어줄 것이다. 기본적인 모습은 아래와 같다

쉽게 말해, 먼저 카카오톡 실행이 되고, 알아서 하다가- 나한테 코드를 줄테니 토큰 발급을 1회 하고 너 하고싶은대로 하면돼 ~ 라는 의미

초기 코드를 아주 상세하게 설명해줘서 좋았다. 라고 하기엔 이거 찾을라고 난리를 침 ㅜㅜ 좀만 더 잘보이게 해줘요

저기 ${VERSION} 이랑 ${INTEGRITY_VALUE} 은 JavaScript 시작하기-다운로드 에서 찾을 수 있다.

남은 내용은 저기 있는 노란 하이라이트를 누르면 그냥 스크립트 코드 전체를 준다. 만약 그게 싫다면 VERSION을 직접 찾고, 해당 버전의 INTEGRITY_VALUE 값을 복사해서 넣어주자. INTEGRITY_VALUE 값은 저 노란 버튼 말고 그 옆에거 누르면 던져준다.

그리고 저 초기화 코드를 이용해서 초기화를 해본다.

아, 저기 JAVASCRIPT_KEY는 API 활용 토큰 같은 거다. 내 애플리케이션 > 앱 키 > JavaScript 키 에서 찾을 수 있다.

True를 던져준다.

파라미터는 이렇게 던져줬다.

기본적으로 이렇게 하면 웬만하면 알아서 앱이 열리고 알아서 불러가지만, 앱이 없는 경우는 오류가 생긴다. 본부장님이 확인해주셨다ㅜㅜ

그래서, Docs를 샅샅이 뒤져보니 이런 말이 있었다. ( 는 무슨 바로 아래 있는데 안읽음 )

즉, error가 떨어질 수도 있다는 것.

그럼 Callback 측에서 이 내용에 대한 것들도 redirect로 보내줘야 한단 말씀

그럼 그냥 웹페이지로 가서 아이디랑 비밀번호 입력하게 만들면 된다.

여기를 참고하여 header에 Location을 잡아준다.

https://kauth.kakao.com/oauth/authorize?response_type=code&client_id=${REST_API_KEY}&redirect_uri=${REDIRECT_URI}

사실 너무 쉽게도, 예제가 있었고 여기 그대로 쓰면, 동작된다.

3. 토큰

JS로 구현할 거라면, 여길 참고하면 된다.

나의 경우 말했다시피 DB 적재도 있고 해서 그냥 php 파일로 만들었다.

php 파일은 REST API로 이용해야함.

파라미터는

https://kauth.kakao.com/oauth/authorize?response_type=code&client_id=${REST_API_KEY}&redirect_uri=${REDIRECT_URI}

이런식으로 만들어서 보내면 된다.

REST_API_KEY는 아까 그 앱 키를 넣으면 마무리-

끝!

중간에 도저히 안풀리는 문제가 있어서 지선생님 도움을 좀 받았다..^^!

AWS에서 사용하니 당연히, 두 DB 간의 보안 그룹을 열어주어야 한다 😕 두 인스턴스 간의 보안 그룹 설정 및 Public Subnet으로의 ssh 연동이 확인되었다면, 설정을 시작해보자.

일단, mariadb 최신 버전에서는 my.cnf를 쓰지 않는다. 고로 my.cnf 를 하루종일 변경해도 변경점이 저장되지 않음.

이 내용을 지선생이 몰랐나보다. 계속 my.cnf를 던져주길래

라고 물어보니까 이렇게 대답하드라구여,,,, ^^ 이좌식이 ~! 처음부터 제대로 검색하란말이야ㅠㅠ!!

이래서 내가 지선생을 안쓰는건데.. 회사 오니까 다들 쓰고있어서...나도쓰게...되었다

1. Master의 50-server.cnf 변경

server-id=1
log_bin=mysql-bin
binlog_do_db=your_database  # 복제할 데이터베이스 이름

이렇게 써줄건데, binlog_do_db 옵션의 경우 복제할 '데이터베이스' 이름이므로, 전체를 다 백업하는 용도라면 설정하지말자!

이렇게 하고, 꼭 systemctl restart mariadb를 한번 해주자. 안하고 show master status를 때리니까 암것두 안나온당 😕

2. Master 에서 Replication 계정 생성

CREATE USER 'replica_user'@'%' IDENTIFIED BY 'passwd';
GRANT REPLICATION SLAVE ON *.* TO 'replica_user'@'%';
FLUSH PRIVILEGES;

유저를 생성해준다. 이 유저는 Slave 쪽에 crud를 해줄 아이인 것으로 보임! (내가 이해한거라 확실 X)

SHOW MASTER STATUS;

마스터의 설정을 확인해서, Slave에 전달해주어야 Slave로 Master의 기록을 찾아서 가져갈 수 있으므로, 마스터의 정보 조회를 해준다.

이런식으로 나올것이다.

여기의 File 과 Position을 써먹어야 한다. binlog_do_db는 위의 옵션을 추가할 경우 나오는데, 나는 추가안했으므로 안나온당!

3. Slave DB의 50-server.cnf 설정

server-id=2
relay-log=mysql-relay-bin

server-id 가 master/slave를 나눠주는 priority 처럼 작동하므로 server-id를 중복시키면 안된다! 그리고 relay-log의 경우

이런거라고 한다. 옵션이랑 같이 생각해서 체크해보면, Master 서버가 bin log에 변경된 애들을 기록해두면 slave가 와서 bin log를 읽어가고, 이 bin log를 relay log에 저장해두고 자기 DB에 업데이트를 시킨다고 보면 된다. 따라서 relay-log의 이름을 저장하라는 뜻임.

헷갈렸던 부분을 말하자면, log_bin 옵션과 relay-log 둘 다 log 파일의 이름을 저장하는 것이다. 처음 cnf 파일에는 위치가 저장되어 있을건데, (/var/log/...) 그렇게 하면 해당 로그 파일의 권한을 다시 설정해줘야 하고, 귀찮은 일들이 생긴다고 한다. 따라서 datadir이 디렉토리를 알아서 설정하게 내버려두고, 우리는 이름만 정해주자.

4. DUMP하기

내가 이것때문에 시간을 2시간이나 잡아먹었는데,,;; 나는 slave 한테 bin 정보를 주길래 '아 현 상태를 알아서 복제하나보다' 했는데 그게 아니었음. 처음에는 database와 데이터들을 직접 dump 떠서 넣어줘야 한다고 한다.

따라서 master 서버에서 dump를 떠서 slave 서버로 보내주자.

대충 이렇게... ssh 접속할 수 있는 web 서버에서 옮겨줬다. 나는 pem키 때문에 master에서 slave로 바로 전송 안될거라고 생각했는데 (당연히 두 DB서버 AZ 다름) 되는거같기도 하고...?ㅠㅠ 잘 모르겠다 아무튼 이렇게 옮겨줬다

5. Master과 Slave 둘 다 restart 하기!

이것때문에.. 미리 하는거임 ㅠ 오류가 생기면 계속 restart 해줘야한다,,,

6. Slave 에서 Master 정보 설정하기

설정이 끝났으면, Slave한테 나 완료되었으니 이제 Master 정보 입력해줄게 ~ 시작해 ~ 라고 알려줘야한다.

CHANGE MASTER TO
  MASTER_HOST='Master_DB_Private_IP',
  MASTER_USER='replica_user',
  MASTER_PASSWORD='passwd',
  MASTER_LOG_FILE='mysql-bin.000002',
  MASTER_LOG_POS=93704;

아까 show master status 해서 나온 값을 여기에 알려줘야한다. 니 마스터는 이 사람이야~ 이 사람의 초기 데이터는 이래~ 라고 알려주는 것과 같다.

7. Slave 복제 시작

START SLAVE;
SHOW SLAVE STATUS\G;

slave 복제를 시작하고, 복제가 되고 나면 status로 현 상태를 확인해준다.

대충 이런식으로 뜬다. Waiting for master.. 어쩌구 뜨면 성공이다.

계속 Connecting 상태로 있을 경우 아래쪽을 읽어보면 Error가 보인다. 나의 경우 ip를 복사해서 썼더니 '100.10.10.10' 이 아니라 '100-10-10-10' 이렇게 넣어서 에러가 났다.

따라서 트러블슈팅을 해주면 된다.

8. 확인하기

정상적으로 동작하는지 확인하고 싶다면, master에다가 데이터를 하나 넣어보자. 그리고 나서 slave에 데이터가 있는지 확인하면 된다!

업데이트가 잘 되고 있는 경우 데이터가 잘 들어오고 status에도 따로 error가 뜨지 않는다.

끝 -

출처 : 개발진스 짤 dev-hee 님 😃https://velog.io/@heelieben/%EA%B0%9C%EB%B0%9C%EC%A7%84%EC%8A%A4-%EC%A7%A4-%EB%8D%B0%EB%A0%A4%EA%B0%80%EC%84%B8%EC%9A%942

너무 간단해서 ㅠ.ㅠ 그래도 일단 저장용으로 ..

참고로, nat 게이트웨이는 시간당 0.059 USD의 돈이 나간다. 따라서 필요할 때 잠시 쓰고, 1시간이 되기 전에 반납하자. 반납할 때 EC2와 달리 Elastic IP는 자동으로 반납되지 않으므로 Elastic IP는 꼭 따로 반납해주자.

난 어제 깜빡하고 켜고 갔다^^

1. NAT Gateway 생성

NAT Gateway를 생성해준다. Subnet 선택에서 Subnet은 public 을 설정해줘야 한다. 뭐가 public 인지 모르겠다면 라우트 테이블로 가서 igw 룰이 들어있는 서브넷이 연결된 애가 누군지 알아보자. 그럼 그 친구가 public subnet이다.

퍼블릭을 생성 후, Elastic IP를 연결해주는데, 만약 기존에 할당받은 Elastic IP가 없다면, 탄력적 IP 할당 버튼을 눌러서 새로 하나 발급받아주면 된다.

그리고 생성을 눌러준다.

2. 라우팅 테이블 연동

여기까지 했으면 이제 private subnet에 연동된 route table한테 가서, 너는 인터넷을 하고싶으면 여기로 가라. 라고 알려줘야한다.

private subnet에 가서 라우팅 편집을 누르고 라우팅 추가를 한 다음에

이런 식으로 NAT 게이트웨이를 선택해서 연결해주면 끝

3. 테스트

ssh로 접근해서 ping을 날려본다

올라오는데 좀 걸릴수도 있다. 실제로 어제는 1분 좀 넘게 걸렸는데 오늘은 1초만에 된다;ㅅ;

4. mariaDB install

참고로 apt update를 하지 않으면 이상한 Error가 뜬다

Unable to locate mariadb-client 이런 거... apt update를 해줘야한다.

그러고 나면 다운로드가 잘 된다.

5. NAT 게이트웨이 반납

꼭! 돈 폭탄을 맞고싶지 않다면 반납하라!!

6. Elastic IP 릴리즈

이것도 꼭! 해주어라!

7. Route Table 룰 변경

이건 돈이 나가는 건 아니지만, 나중에 보면 갑자기 블랙홀이라고 떠서 놀란다 그러니까 한번에 해주자

아무튼, 오늘은 Better Stack + Slack으로 간단한 https 모니터링 시스템을 구축해본다. (구축이라고 하기도 뭣하네)

결론부터 말하자면, 모니터링에는 여러가지 대안이 있다. 서버 다운이 크리티컬하지 않은 경우, (그런 경우는 없겠지만) 지금처럼 3분에 한번 정도 체크를 해서 살아있는지 확인하는 방법이 있고, 좀 더 큰 구조에서는 CloudWatch + lambda + SNS 등을 이용해서 모니터링 알림을 받는 방법이 있을 것이다. 해당 구조도 생각해봤지만, 우리는 API서버가 많고, 각 서버에서 CPU 사용량이나 이런게 많아질거라고는 생각하지 않아서, 떠있는 웹서버에서만 헬스 체크를 하면 될 것 같아서 그냥 무료로 사용할 수 있는 툴을 이용했다.

지선생은 처음에 UptimeRobot을 추천했는데, UptimeRobot은 더이상 Webhook과 Slack을 무료로 제공하지 않는다. 실제로 지선생한테 안되는데? 를 세번 말하니까, 지선생이 '이제 더이상 제공하지 않나봐요' 라고 말하더라 ;ㅅ; 그럴거면 처음부터 알려주지..! 회사 계정이라 계속 요청해야한단말이야!!!

그 다음 대안이 바로 Better Stack이었다. Better Stack 사용은 간단하다.

1. Better Stack Setup

일단 Sign up을 한 다음 (메일 승인) First Name, Last Name 등을 기입한다. 그리고 https:// [ 주 소 ] 를 입력하라고 말하지만 입력하고 번호를 눌러도 알림은 안온다.

그러면서 하는 말이, ' 앗 미안 한국은 안되나바 엣큥 ' 이었음 ㅋㅋㅋㅋ

그래서 그냥 Dashboard로 넘어간다..

2. Integrations

왼쪽 사이드바에서 Integrations를 선택하고, Slack을 추가한다. 그럼 웹에 로그인된 슬랙이랑 바로 연동됨

이렇게 연동이 되면, 서버 상태 알림 채널에 알림이 들어온다!

3. test

테스트로 서버 하나를 중지시켜본다.

안농...

그러고나면

한 2분쯤 뒤

짜잔

야야 니네 서버 응답 안주는데? 하고 알림줌 끝- 너무쉽네...

런칭 전이라 나빼고 다바빠 ㅜㅜ.ㅜ.ㅜ.ㅜㅜ

오늘 치과다녀와서 저녁에 만든거... 진짜 저 작은 픽셀 하나하나 맞춰주는게 너무 힘들고 디자인 어떻게 할지 생각하는것도 너무 힘들다. 분명히 예쁘게 됐을거라고 생각했는데 너무 별로임... ㄸㄹㄹㄹㄹㄹㄹㄹ....

어쨌든, 이 사이트는 Codeply라는 곳인데 작성하면서 바로바로 확인할 수 있어서 참 좋음,,,,

https://www.codeply.com/

로그인하면 저장도 가능한 것 같구 다른 사람들의 코드도 참조할 수 있는 듯 하다...

그리고 이미지는 저작권 없는 사이트를 돌아다니다가

https://pixabay.com/illustrations/writer-book-table-candlesticks-8752968/

대부분 외국 사이트라 외국 사이트에서 파밍했다.

VSCode에서 Remote-SSH 설치

설치한 후에 리로드 한번 필요

그리고 나서 구성 파일 열기 클릭 후 구성 파일 작성

이렇게 하고 나서 호스트에 연결을 눌렀으나 에러 메시지 없이 실패만 계속 함

역시 permissions are too open 이지 않을까 싶어서 pem키의 권한을 변경해줌 Windows의 경우 권한 변경은 아래 선생님의 블로그에서 잘 설명해주셨따

ref: https://velog.io/@jinhoss/ssh-permissions-for-too-open-%EC%97%90%EB%9F%AC-%ED%95%B4%EA%B2%B0

그리고 나서 시도하니 정상작동

간단하게 올린 것이므로 인스턴스 유형이 매우 작지만... 개인 웹페이지는 이정도면 일단 충분할 것으로 생각된다.

먼저 Structure를 보자

private subnet은 amazon linux 위에 직접 올린 nat instance를 이용해 외부와 통신하고, 비용적(그리고 여러 이유..)인 측면을 고려해 nat instance는 bastion host의 역할도 겸하여 DB Instance에 ssh 통신이 필요할 경우 nat instance를 통해 통신할 수 있도록 bastion host의 역할도 주었다.

이 과정에서 nat instance 설정은 내 게시글 NAT Isntance 직접 구축하기를 참조하였고, en0X eth0 의 문제가 잠깐 있었지만 트러블슈팅 후 게시글에 추가해두었다.

django 설치 및 연동은 이 게시글 django로 웹페이지 만들기를 통해 진행하였다.

VPC 생성 및 Subnet 나누기

기본적으로 VPC는 인스턴스를 생성하는 순간 하나 만들어주는데, 해당 VPC의 subnet은 public subnet 뿐이므로 private subnet을 채용하고 싶다면 subnet을 추가해주어야 한다.

기본으로 있는 subnet 중에 웹이 올라가있는 하나를 public으로 하고 private을 생성하였다.

만들때는 따로 private이라는 옵션이 없는데, 그것은 당연하게도 라우팅 테이블을 연동해줄 때 private과 public을 사용하기 때문이다.

Route Table 만들어주기

라우팅 테이블로 가서 설정이 하기와 같이 되는 테이블을 하나 만들어준다.

첫번째 규칙에서 대상은 nat instance이고 두번째 규칙은 vpc내의 vm끼리 통신하겠다는 내용이므로 이 라우팅 테이블을 private subnet에 연동시켜준다.

NAT INSTANCE 설정하기

이외에는 이전에 nat instance 설정한것과 똑같이 하면 된다.

그러면 간단하게 웹 , DB , nat 가 존재하는 라이트한 구조를 만들어볼 수 있다.

오늘 하룻동안 한거 ..^^

일단 django 설치 등은 해당 블로그를 많이 참고했다

ref: https://lucky516.tistory.com/58

최대한 필요한 정보만 담아먹었다..!

또한 DB 연동은 해당 블로그를 참조하였음

ref: https://velog.io/@dustndus8/Django5.-DB-%EC%97%B0%EB%8F%99

1. django 설치 및 runserver

기본적으로 첫번째 블로그의 1번 포스팅을 참고하면 좋다.

다만, runserver를 할 때 나의 경우 AWS Instance를 이용했기때문에 localhost로 접근하는게 아니었다.

따라서 runserver 커맨드는 하기와 같다.

python3 manage.py runserver 0.0.0.0:8000

2. startapp

첫번째 블로그의 2번 포스팅을 참조하여 startapp을 진행하면 된다.

나의 경우, HttpResponse를 주고 싶었던 게 아니라 메인페이지를 보여주고 싶었기 때문에 해당 부분만 변경하여 진행했다.

board/index.html 파일을 찾아갈 수 있도록 리턴해준다.

3. DB 연동

여기서부터 첫번째 블로그와 다른 점이 있는데, 나의 경우에는 DB 연동을 따로 할 것이기 때문에 기본으로 제공하는 DB를 사용하지 않는다. 따라서 settings.py로 가서 DB 설정을 해주어야 한다.

DB 설정을 해주고 (나중에 꼭 바꾸자) makemigrations를 해주면, 잘 작동되는 것을 확인할 수 있었다.

내친김에 쿼리도 한번 불러봐준다

4. 간단한 프론트페이지 작성

여기서 첫번째 블로그 선생님께 감사함이 느껴졌다,,, 일단 , templates를 어느 경로에 생성해야하는가를 아무 블로그에서도 알려주지 않았다,,, 속상

첫번째 블로그의 5번 게시글로 바로 넘어가서 참고하였다.

감사합니다 감사합니다 감사합니다...

해당 위치에 템플릿 디렉토리 생성 및 index.html을 만들어보면... 나만의 웹페이지 메인 완성..!

이제 프론트 작성해야한다 귀찮아~!!!!!!!!!

https://stackoverflow.com/questions/75951019/unable-to-install-mysqlclient-package-on-ec2-instance/75957438#75957438

스택 오버플로에서 해결 ㅠ

mysql -u root -p

임시 비밀번호는 /var/log/mysqld/log 안에 들어있다. temporary password is ~ 이런식으로 서술되어 있을 것이다.

해당 비밀번호 이용하여 접속

2. 비밀번호 변경

ALTER USER 'root'@'localhost' IDENTIFIED BY '[새로운 패스워드]';
FLUSH PRIVILEGES;

이 경우 ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

이런 오류가 뜰 수 있는데 이것은 내 비밀번호 설정에 맞지 않아서.. 그냥 설치했더니 STRONG으로 되어 있어서 대문자, 소문자, 특수문자, 숫자를 모두 포함한 8자리 이상이어야 한다고 한다

3. my.cnf 찾기

나의 경우 /var/안에서 my.cnf를 찾았다.. my.cnf 안에 들어가서 기본적인 설정을 해주는데

bind-adress=0.0.0.0 주석 처리도 같은 의미임

외부 접근 허용을 열어준다.

4. 유저 추가 및 데이터테이블/테이블 생성

ref : https://dev.classmethod.jp/articles/ec2-mysql-install-confilicting-requests-error-kr/

ref : https://velog.io/@yushinc/Error-GPG-check-FAILED

Amazon Linux 2023 + 버전이라면

sudo dnf install https://dev.mysql.com/get/mysql80-community-release-el9-1.noarch.rpm
sudo dnf install mysql-community-server

해당 방법으로 repo 추가 및 설치를 해주어야 한다.

/etc/yum.repos.d 내에 있는 amazonlinux.repo에 mysql-community-server 추가가 기본적으로 되어 있지 않기 때문에 설치가 불가능하므로 해당 방법이 필요하다

이렇게 설치를 하면 문제가 생기지 않지만, 이렇게 설치를 하지 않은 경우

conflicting requests 라는 에러 메시지를 마주하게 된다.

이것은 지원하지 않는 버전의 mysql을 설치한 것으로, 다시 설치해주면 된다.

이렇게 다시 설치할 경우

Error: GPG check FAILED 이 에러를 한번 더 보게 되는데, 이는 이전에 설치했던 키 값과 키 값이 충돌이 나서 확인이 되지 않는 경우인 것 같다.

따라서

rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2023

설치한 버전으로 키 값 갱신을 해주면 정상적으로 설치된다.