K

could not find jruby in D:\ELK\logstash-8.11.3\vendor\jruby\bin\jruby java 문제가 해결되니 jruby 파일을 못찾는다는 에러가 발생했다. 해당 폴더 위치로 가보니 vendor 폴더 안에 jruby 폴더는 없었고, bundle 폴더만 있었다. bundle 폴더 안에 jruby 폴더가 있길래 그 폴더를 밖으로 꺼내도 같은 오류 발생 처음 logstash를 다운받고 압축을 2번 풀었었는데 처음 거는 17개 항목이었고 다음 거는 15개 항목이었다. 혹시.. 하는 마음에 새로 다운받아 압축을 풀어보니 17개 항목이 되었고 vendor 폴더 안에 bundle 폴더와 jruby 폴더가 있었다. 압축 해제할 때 뭔가 제대로 안됐다보다 .. 억울하다 .. 해결됐..

"Using system java: "C:\Program Files\Java\jdk-21\bin\java.exe"" The specified path cannot be found. could not find java; set JAVA_HOME or ensure java is in PATH java 설치와 환경 변수 설정은 제대로 되어 있다. java --version 명령어와 javac --version 명령어가 정상적으로 출력 된다. 즉 JAVA_HOME 변수는 제대로 설정 되어 있고, java.exe 파일 또한 확실히 존재한다. 그러나 계속해서 같은 오류가 발생했다. elastic search와 kibana는 문제 없이 구동되는데 logstash만 오류가 발생했다. 아무리 검색하고 찾아도 해결이 안됐..

로컬에서 카프카 구축 후 토픽 발행, 구독 테스트를 진행했다. 토픽 생성, 메세지 전송은 성공적으로 이루어지나 구독하여 메세지를 받아올 때 오류가 발생했다. kafka-console-consumer.bat --bootstrap-server localhost:9092 --topic test --from-beginning 해당 명령어 실행 후 구독한 토픽의 메세지가 뜨지 않고 가만히.. 있었다. 강제 종료 후에는 Processed a total of 0 messages 문구가 나타났다. 카프카 실행창을 보니 Unexpected error handling request RequestHeader 라는 에러 로그를 확인할 수 있었다. 해결 방법은 구독 명령어에 --partition 0 을 붙여 파티션의 개수를 지..

워크로드 쿠버네티스 상에서 작동되는 애플리케이션 +) 클라우드 분야에서는 애플리케이션을 실행할 때 필요한 IT 리소스의 집합이라는 의미로 통용됨 파드(Pods) 쿠버네티스의 배포 가능한 가장 작은 컴퓨팅 유닛 그 자체로 하나의 논리적인 호스트 파드에 포함된 항목(도커 컨테이너처럼 파드 내에서 다음 요소들은 격리됨) 하나 이상의 애플리케이션 컨테이너 IP 주소 볼륨과 같은 공유 스토리지 파드를 생성하기 위해 파드를 정의할 때, YAML 파일을 사용할 수 있음 apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 YAML 파일로 정의된 파..

쿠버네티스 아키텍처 클러스터는 하나 이상의 제어판(Control Plane) 컴포넌트와 이와 연결된 몇 개의 워커 노드로 구성됨 워커 노드 kublet이라는 프로세스가 돌가가고 있는데, 이는 다른 노드와 서로 통신하거나 컨테이너를 실행하는 등 태스크를 실행할 수 있게 함 워커 안에는 한 개 이상의 컨테이너가 자리잡고 있음, 즉 워커 노드는 실제로 애플리케이션이 실행되고 있는 곳 컨테이너, 볼륨, 작동 정보 등을 파드(Pod)라고 부름 제어판(Control Palne) 관리를 위해 필요한 프로세스들이 존재하며, 클러스터가 잘 작동할 수 있게 도움 API 서버 모든 클러스터 관리의 입구로서, 명령을 내릴 수 있는 관문 쿠버네티스에서 제공되는 UI, CLI 등에서 클러스터 관리를 위해 명령을 내리면 API가 ..

컨테이너 오케스트레이션 수십~수백 개의 컨테이너를 관리하고자 할 때 사용하는 툴 왜 수십~수백 개의 컨테이너가 필요한가? - 아키텍처의 트랜드: 모놀리식 -> 마이크로서비스 - 컨테이너 개수 증가 - 확장성을 고려한 스케일링 쿠버네티스(Kubernates, k8s) 오픈소스로 만들어진 컨테이너 오케스트레이션 도구 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링하는 등 관리 기능 제공 온프레미스, VM, 클라우드 등 각기 다른 환경에 대응 가능 사용이 적합하지 않은 경우 여러 단계로 나뉘지 않은 모놀리식 아키텍처 마이크로서비스 분해 전략을 세우는 것이 우선 서너 개에 불과한 컨테이너 docker-compose로 충분 비교적 단순한 아키텍처, 스케일링이 필요하지 않은 경우 트래픽이 증가하거나 스케일링이 ..

AWS Access key와 Secret key는 깃허브 레포지토리 환경설정의 액션 환경변수에 저장 name: Publish Docker Image and Deploy to Amazon ECS on: release: workflow_dispatch: env: AWS_REGION: ap-northeast-2 # set this to your preferred AWS region, e.g. us-west-1 ECR_REPOSITORY: your_repository # set this to your Amazon ECR repository name ECS_SERVICE: your_service # set this to your Amazon ECS service name ECS_CLUSTER: your_clust..

개발자가 새로운 버전을 릴리즈하면 Git Action을 통해 자동화되어 진행됩니다. ECR 이미지 Push, 새 태스크 정의 생성, ECS 서비스 업데이트가 포함됩니다. Route 53을 통해 지정한 도메인으로 사용자가 api 요청을 보냅니다. DynamoDB에 접근하여 CRUD 요청을 처리합니다. 전체 파일 구성은 다음과 같다. 관리를 위해 서비스 별로 파일을 나누어 구성하는 것을 선호한다. main.tf provider "aws" { region = "ap-northeast-2" } vpc.tf # vpc 생성 resource "aws_vpc" "mb_vpc" { cidr_block = "10.0.0.0/16" enable_dns_hostnames = true tags = { Name = "mb_vp..

ResourceInitializationError: unable to pull secrets or registry auth: execution resource retrieval failed: unable to retrieve ecr registry auth: ... 에러가 발생하며 태스크가 정상적으로 생성되지 않는 상황이 발생했다. 시도한 방법 1. IAM 정책 추가: AmazonEC2ContainerServiceforEC2Role 정책을 추가하면 된다는 의견이 많았다. 시도해보았으나 같은 결과가 발생했다. 2. vpc 엔드포인트 추가: ecr.dkr과 ecr.api 엔드포인트를 추가하라는 글을 몇 개 발견했다. 추가하였으나 같은 결과가 발생하였다. 3. 퍼블릭 ip 할당 활성화: 해당 방법으로 성공하였..

ECR의 푸시 명령으로 이미지를 올릴 때 retrying in seconds가 계속 반복된 뒤 EOF가 나오며 실패하는 에러가 발생했다. ECR의 권한을 추가하여 해결할 수 있다. { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowPushPull", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "ecr:BatchCheckLayerAvailability", "ecr:BatchGetImage", "ecr:CompleteLayerUpload", "ecr:GetDownloadUrlForLayer", "ecr:InitiateLayerUpload", "ecr:PutImage", "ecr:UploadLa..