Q. 프로젝트가 끝난 지금, 어떤가요?
A. 으아ㅏㅏㅏㅏㅏ
지금의 나의 상태. 완성? 미완성? 그 애매한 경계에서 프로젝트가 마무리가 되었다

📚Project

제공해주는 주제가 있었는데 2가지 정도는 확정 주제고(이미 시나리오와 요구사항이 있는것!) 주제 자유해서 총 3가지의 주제를 고를 수 있었다. 주제를 고르는 순서는 랜덤 프로그램을 통해 공정하게 정해졌다. 우리 조는 자유 주제를 선정했고, 자유 주제의 필수 포인트는 컨테이너 기반이었다. 컨테이너 기반으로 주제를 정해야하는 것. 무엇을 할까 하며 폭풍 회의를 하다. 평소에 방송을 실시간으로 보지는 않지만 유튜브 러버로서 트위치라는 플랫폼에서 방송하는 분들의 유튜브를 보다보니 익숙한 시스템인 미션 후원 시스템에 대해서 제안을 했다. 다른 팀원분들의 첨삭을 걸쳐 나쁘지 않다는 이야기가 나오고 얼떨결에 내가 제안한 주제로 결정되었다. 와!🙋‍♂️

📑시스템 분석 및 요구사항

다음은 팀원들과 시스템에 대해서 분석하고 요구사항에 대해서 미팅한 결과이다.

• 프론트엔드는 일단 배제하였다 : 팀원들의 개발 레벨이 높지 않고, 완성에 집중하기 위해

프로젝트 주제: 미션 관리 서비스

• 기능 요구사항

  • 개인 사용자와 스트리머는 로그인 기능을 통해 토큰을 발급받을 수 있다.
  • 토큰을 사용하는 로직 구현이 어렵다면 유저 데이터베이스에 접근해서 일치하는 사용자 정보가 있는 것을 확인하는 것으로 대체
  • 개인 사용자 새로운 미션을 입력 및 조회할 수 있다.
  • 스트리머는 미션에 대해 성공 및 실패를 선택할 수 있다.
  • 성공 및 실패가 결정된 경우 개인 사용자는 해당 미션의 결과에 대한 email을 받을 수 있다.
  • 미션을 수행하는 제한시간을 설정할 수 있다.
  • 캐쉬를 충전하는 기능, 미션마다 포인트 설정, 성공하면 지급되야되고 실패 시 반환된다.
  • 이미 생성된 미션에 경우 생성한 유저 이외의 유저도 캐쉬를 추가할 수 있다.

• 추가적인 사항

  • 해당 미션에 성공할지 못할지에 대한 게임이 있다.

• 인프라 요구사항

  • 시스템 전반에 가용성, 내결함성, 확장성, 보안성이 고려된 서비스들이 포함되어야한다.
  • 하나 이상의 컴퓨팅 유닛에 대한 CI/CD 파이프라인이 구성되어야한다.
  • 유저 데이터를 저장하고 있는 유저 데이터베이스는 다른 데이터베이스와 분리되어있어야한다.
  • 미션 데이터를 기반으로 미션 성공에 대해 처리하는 시스템은 데이터 유실을 막기 위해 느슨하게 결합되어야한다.
  • 시스템 메트릭 또는 저장된 데이터에 대한 하나 이상의 시각화된 모니터링 시스템이 구축되어야한다.

🖌 다이어그램

위의 시스템 분석과 요구사항을 토대로 다이어그램을 그렸다

아키텍처

아키텍처를 그려보면서 아쉬웠던게 생각보다 시스템이 간단하였다. 솔직히 말해서 3티어만 해도 충분히 시스템을 만들었다. 그래서 우리조는... 온 몸을 비틀어버렸다

DB

🔧 개발 시작

처음부터 문제다 문제

처음 작업했던 것은 AWS VPC 작업을 통해 네트워크 공간을 개발하는 거였다.

하지만 여기서부터 잘못 되어갔는데... 뒤에 바로 말하겠다. AWS VPC 작업 할 때 AWS Console 작업이 아닌 바로 Terraform 으로 들어갔다. 이유는 간단했는데 한번에 리소스를 관리할 수 있기 때문이었다.

잘못은 이 프로젝트의 시스템 인프라는 증명이 안되었다는 것 컨셉 증명을 확실히 하고 시스템을 처음에는 콘솔작업으로 한땀한땀 하여 'hello world' 가 나오는 간단한 애플리케이션이라도 배포를 하고 Terraform 으로 VPC 를 만들다 보니 이후에 모든 작업을 바로바로 Terraform 으로 작업을 하게 되었다. 1부터 하여야 할 것을 10부터 진행하고 있었다. 이러한 피드백을 받았을 때 '앗' 하는 충격과 동시에 시무룩해졌었다... 잘못도 잘못이지만... 그래도 노력한 게 있었던지라

그럼에도 시무룩하고 있을 시간은 없었고 작업은 해야했다. 피드백을 적극 수용하여 이후 이미 Terraform 으로 만들어진 리소스는 어쩔 수 없다고 생각하고 AWS Console 로 최대한 증명해가면서 작업하였다.

EKS 트러블 슈팅

EKS 작업 중 가장 나를 힘들게 했던것은 EKS Cluster 와 Worker Node 통신 에러 문제였다. WorkerNode 는 Cluster 와 통신을 해야하는데 자꾸 통신 에러가 뜨면서 Bastion Host 를 통해 WorkerNode Instance 로 접속을 할 수 없었다. 그러던 중에 Worker Node 를 private subnet 중에 첫 번째 subnet 에 고정적으로 넣으면서 통신 에러 없이 Worker Node 가 잘 생성이 되면서 접속이 되었다! 이제 설정을 private subnet 전체를 지정하고 되겠지 기대하면서 다시 돌렸지만 에러가 돌아왔다. 여기서 잘 하시는 분은 바로 문제를 찾겠지만 문제는 네트워크 였었다. 통신 에러니깐 당연히 네트워크 에러가 맞지만 같은 VPC 안이라고 생각했던게 달랐었다. public host 에서 bastion host 가 있는 public subnet 은 private subnet 1번과 NAT Gateway 로 연결되어 있다.

• bastion host (public subnet 1번) 를 통해 worker node (private subnet 1번) 접속

딱 이렇게 Bastion Host 만을 생각하고 작업을 해서 private subnet 1번에 worker node 를 배치하면 잘 되고 다른 곳은 연결이 안된다. 왜? NAT Gateway 가 private subnet 1번 하고만 연결 되어있으니깐. 또한 Worker Node Group 은 연결된 서브넷에 랜덤한 위치에 Worker Node 를 배치하기 시작한다

이 문제를 알게 되고나서 EKS 가 VPC 외부 시스템인걸 인지하게 되고 NAT 를 전부 연결하게 되면서 문제는 해결 되었다.

kubectl EKS 접속 시 사용자 등록

기본적으로 Amazon EKS 의 경우 Cluster 생성자가 사용자로 지정되어 있으며 master 권한을 가지고 있다. 외부에서 예를 들어 EKS 관리팀의 신입이 kubectl 을 통해 EKS 를 보고 싶을 때 사용자로 등록되어 있지 않다면 Cluster 를 확인할 수 없다. AWS Cloud 환경을 우리 팀장님의 계정으로 만들었기에 추후 로드 밸런싱 작업을 위해 kubectl 접속이 필요했다. 그러기 위해 다음과 같은 사용자 추가 과정을 팀장님께 부탁을 드렸다.

• 등록 하고자 하는 AWS IAM 사용자를 만든다.
  • IAM 사용자는 내 AWS 계정에서 만들었다.
  • 해당 IAM 사용자의 ARN 이 필요
• 공통)

  • # AWS 권한 Config map 확인 명령어를 통해 
    kubectl get -n kube-system configmap/aws-auth

• 방법1) eksctl 사용

  • eksctl create iamidentitymapping \
    --cluster cluster-name \ # 클러스터 네임 (자신의 AWS 에 EKS 가 존재해야함)
    --region=ap-northeast-2 \
    --arn arn:aws:iam::111122223333:user/ggamzzak \ # 아까 생성한 사용자의 ARN
    --group system:masters \
    --profile my-profile # AWS Configure 를 통해 AWS CLI Access Profile 등록되어 있어야 한다.

• 방법2)

  • # AWS 권한 Config map 수정 명령어를 통해 수정이 가능하다. 
    kubectl edit -n kube-system configmap/aws-auth

  • # aws-auth.yml
    mapUsers: |
     - userarn: arn:aws:iam::002672955123:user/test1
       username: test1
       groups:
       - system:masters
       # 여기서 아까 생성한 ARN 을 넣어주고 
     - userarn: arn:aws:iam::002672955123:user/test2
       username: test2
       groups:
       - system:masters  # 해당 유저의 권한을 설정한다.

• 사용자 추가후 kubectl 로 클러스터를 확인할 수 있다.
  • kubectl 은 관리자 또는 클러스터 생성자로부터 kubeconfig 파일을 받아 연결이 가능하다.

    AWS LoadBalancer Controller 자격 증명

    https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/aws-load-balancer-controller.html 보면서 따라하였다 쿠버네티스가 직접 관리하는 사용자 계정을 의미하는 service account에 IAM role을 사용하기 위해, 생성한 클러스터(현재 실습에서의 eks-demo)에 IAM OIDC provider가 존재해야 합니다.
  • 클러스터 생성자에게 생성의뢰

    # IAM OIDC(OpenID Connect) identity Provider를 생성
    eksctl utils associate-iam-oidc-provider \
    --region ap-northeast-2 \
    --cluster mission-link-eks-cluster \
        --approve \
        --profile admin

AWS Load Balancer Controller의 kube-system 네임스페이스에 aws-load-balancer-controller라는 Kubernetes 서비스 계정을 생성하고 IAM 역할의 이름으로 Kubernetes 서비스 계정에 주석을 답니다.

eksctl 또는 AWS CLI 및 kubectl을 사용하여 IAM 역할 및 Kubernetes 서비스 계정을 생성할 수 있습니다.

• 클러스터 생성자에게 생성의뢰

# Service Account 계정 생성
eksctl create iamserviceaccount \
  --cluster=mission-link-eks-cluster \
  --namespace=kube-system \
  --name=aws-load-balancer-controller \
  --role-name AmazonEKSLoadBalancerControllerRole \
  --attach-policy-arn=arn:aws:iam::123412341234:policy/AWSLoadBalancerControllerIAMPolicy \
  --profile admin \
  --approve

cert-manager다음 방법 중 하나를 사용하여 웹후크에 인증서 구성을 삽입하여 설치합니다 .

• 노드에 컨테이너 레지스트리에 대한 액세스 권한이 있는 경우 웹후크에 인증서 구성을 삽입하도록 quay.io 설치합니다 .cert-manager

    kubectl apply \
        --validate=false \
        -f https://github.com/jetstack/cert-manager/releases/download/v1.5.4/cert-manager.yaml

AWS LoadBalancer 컨트롤러를 설치합니다.

컨트롤러 사양을 다운로드하십시오. 컨트롤러에 대한 자세한 내용은 GitHub에서 설명서를 참조하십시오.

• EKS 에 맞는 컨트롤러 버전을 써야한다
• 프로젝트의 경우 EKS 2.7 컨트롤러

curl -Lo v2_4_7_full.yaml https://github.com/kubernetes-sigs/aws-load-balancer-controller/releases/download/v2.4.7/v2_4_7_full.yaml

파일에 대해 편집한 항목:

• v2_4_7_full.yaml 파일을 다운로드 한 경우 다음 명령을 실행하여 매니페스트에서 ServiceAccount 섹션을 제거합니다. 이 섹션을 제거하지 않으면 이전 단계에서 서비스 계정에 작성한 필수 주석이 덮어씌워집니다. 이 섹션을 제거하면 컨트롤러를 삭제할 경우 이전 단계에서 생성한 서비스 계정도 유지됩니다.

    sed -i.bak -e '561,569d' ./v2_4_7_full.yaml

  다른 파일 버전을 다운로드한 경우 편집기에서 파일을 열고 다음 줄을 제거합니다.

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      labels:
        app.kubernetes.io/component: controller
        app.kubernetes.io/name: aws-load-balancer-controller
      name: aws-load-balancer-controller
      namespace: kube-system
    ---

• my-cluster를 해당 클러스터 이름으로 바꿔 파일의 Deployment spec 섹션에 있는 your-cluster-name을 해당 클러스터의 이름으로 바꿉니다.

파일을 적용합니다.

kubectl apply -f v2_4_7_full.yaml

ngressClass 및 IngressClassParams 매니페스트를 클러스터에 다운로드합니다.

curl -Lo v2_4_7_ingclass.yaml https://github.com/kubernetes-sigs/aws-load-balancer-controller/releases/download/v2.4.7/v2_4_7_ingclass.yaml

상기 과정을 다 하였을때 Ingress 를 생성하면 AWS 에서 프로비저닝된 ALB 를 생성해주면서 pod 에 접근이 가능해진다.

💭 회고

드디어 말도 많고 탈도 많은 프로젝트가 끝났다. 너무나도 하고 싶었던 팀 단위의 프로젝트. 0에서 무언가를 쌓아가는건 확실히 어렵다는 것을 알게 되었다.

부트캠프를 하겠다고 마음 먹은지가 1년이 넘는데 당연하게도 백엔드 과정을 밟을 줄 알았었는데, 설마 데브옵스 과정을 밝게 될 줄은 상상도 못했다. 계기는 다니고 있던 회사에서 노후 시스템을 업그레이드 하면서 리눅스 환경에서 서버 세팅하고 네트워크 등록하고 하는 작업이 생각보다 재밌었다. 테스트로 서버가 잘 올라갔는지 테스트 할 때 잘 올라간 걸 확인하는 순간 그 뿌듯함이란...

이번 프로젝트에서 아쉬운점이 없지는 않다. 뭔가 더 데브옵스! 하는 아키텍처를 짰으면 하는데 처음에도 글에 썼듯이 온 몸 비틀기를 한 아키텍처가 나와서 아쉬웠고... 아이디어가 더 번쩍였으면 좋았을 거고... 중간중간 정리를 하는 습관을 더 들여야겠다는 생각도 들고... 앞으로 더 잘해가야겠다고 다짐하게 되었다.

불변적 인프라스트럭처는 애완동물과 가축에 대한 비유로 자주 설명 합니다.

애완동물은 이름을 붙이며, 아프면 병원에 데려가고 가족처럼 보살펴줍니다.

하지만 가축은 이름이 아닌 태그를 붙이고, 전염병이 있을 경우에는 처분하게 됩니다.

불변적 인프라스트럭처의 정의는 서버가 설치된 이후 절대 변경되지 않는 형태의 인프라다.

여기서 수정은 기존의 서버를 제거하고 새롭게 만드는 것을 의미

멱등성의 법칙이 적용된다.

• 멱등성 법칙 : 같은 작업을 여러 번 해도 결과가 동일하다. 한번 설정된 서버는 수정 없이 파기되므로 멱등성을 보장한다.

특징

• 각 서버의 버전은 서로 독립적이며 두 가지 버전을 실행할 수 없다
• 변경이 필요할 때 새 버전의 서버를 생성하기 때문에 버전 문제를 추적이 가능하다.
• 각 서버의 구성이 일관되기 때문에 다른 서버를 테스트하고 롤아웃하기 쉽다
• 서버가 동일하게 유지되므로 예측 가능성을 높일 수 있다.
• 클라우드 기술과 같은 상호 의존적인 환경에 적합하다

단점

• 데이터 저장소를 로컬 디스크에 복사하지 않고 외부화해야 한다.
• 기존 서버는 수정할 수 없어 문제 발생 시, 동일 구성의 서버에 대해 점검이 필요하다.

Mutable Infrastructure (가변적 인프라스트럭처)

웹 서버를 만들고 기존의 변경 가능한 인프라에 배포했을 경우, 문제 발생시 서버를 쉽게 변경할 수 있다. 기존 데이터를 새 시스템으로 옮길 필요없이 기존 버전에 변경 사항을 적용한다.

특징

• 변경 필요시 처음부터 서버를 구축할 필요가 없다.
• 개별 서버에 대한 업데이트를 롤 아웃하여 프로세스 업데이트를 더 빠르게 할 수 있다.
• 각 서버를 개별 수준에서 이해할 수 있기 때문에 문제를 진단하기 쉽다.

단점

• 각 서버의 구성이 고유하기 때문에 각 서버를 진단, 관리하는 것이 더 어려워진다. (Configure Draft)
• 서버에 대한 변경사항이 문서화되지 않기 때문에 추적이 어렵고 진단이 불가능하다.
• DNS 오류, 네트워크 연결 불량과 같은 여러 이유로 업데이트가 실패할 수 있다
• 업데이트 추적 문제로 디버깅에 시간이 많이 걸린다. 문제에 대한 이해도 없이 여러 버전의 업데이트로 끝날 수 있다.

차이

• 불변적 인프라는 자동 배포를 지원한다.
  • 이 유형의 인프라는 주로 가상화를 중심으로 구축되기 때문에, 하드웨어와 소프트웨어 프로비저닝 및 디프로비저닝에 대해 걱정할 필요가 없다
• 클라우드에서는 리소스 생성을 위한 모든 프로세스를 문서화할 수 있다
• 데브옵스는 종속성을 제한해야 시간이 절약된다.
  • 자동화된 테스트 및 배포를 지원하는 파이프라인을 생성할 때 수동 검증은 시간이 많이 소요되므로 새로운 어플리케이션을 더 빨리 시작하는 것을 방해한다. 변경할 수 없는 인프라를 사용하여 시나리오를 재현하고 자동으로 재해복구도 가능하다.

불변적 인프라는 장점으로 인프라의 안정성과 신뢰성이 향상되며, 변동성이 줄어들어 관리 및 유지보수가 용이해집니다. 또한, 인프라를 버전 관리하고 롤백이 가능하게 되므로 실수로 발생한 문제를 빠르게 수정할 수 있습니다.

Terraform 상태유지

1. Terraform 코드 작성: Terraform을 사용하여 인프라를 정의하는 코드를 작성합니다. 이 코드는 실제 인프라 구성을 선언적으로 기술하며, 원하는 상태를 나타냅니다.
2. Terraform 초기화: terraform init 명령을 사용하여 Terraform 작업을 위한 초기화를 수행합니다. terraform init 명령은 Terraform 프로젝트를 초기화하고 필요한 백엔드 구성 및 모듈 등의 의존성을 설정합니다.
3. 계획 수립: terraform plan 명령을 사용하여 Terraform 코드를 분석하고 변경 사항을 예측적으로 계획합니다. 이 단계에서 Terraform은 기존 인프라 상태와 코드의 상태를 비교하고 필요한 변경 사항을 탐지합니다.
4. 변경 사항 적용: terraform apply 명령을 사용하여 Terraform 코드에 정의된 변경 사항을 실제 인프라에 적용합니다. Terraform은 변경 사항을 적용하기 전에 변경 내용을 사용자에게 미리 알리며, 사용자의 승인을 받습니다.
5. 상태 관리: Terraform은 인프라의 상태를 추적하고 관리합니다. 인프라 상태 파일에는 현재 인프라 구성이 기록되며, 다음 실행에서 변경 사항을 탐지하고 적용하는 데 사용됩니다.

이러한 과정을 통해 Terraform은 선언적인 코드를 사용하여 인프라의 최신 상태를 유지하고, 변경이 필요한 경우 변경 사항을 감지하고 적용하여 인프라를 업데이트합니다.

AWS에서는 SSL/TLS 인증서에 대한 매니지먼트인 Amazon Certificate Manager 서비스를 무료로 제공한다. 이를 바탕으로 기존 서버 하나하나 일일이 SSL을 적용하였던 번잡한 작업들을 아마존 ACM 서비스를 통해 하나의 인증서로 여러 인스턴스에 적용할 수 있다. _ACM 서비스에 대한 비용은 무료_이나, ELB/CloudFront/API Gateway 등 AWS 인프라에만 적용이 가능한 것을 인지해야 한다

특징

• ACM 서비스에 대한 비용은 무료
• ELB/CloudFront/API Gateway 등 AWS 인프라에만 적용이 가능
• 콘솔상에서 SSL 인증서 키페어는 다운로드가 불가능
• 오로지 AWS CLI를 통해 Public Key Pair만 다운로드가 가능
• ACM 을 통해 SSL 인증서 발급한 경우 다른 사설기관에서 해당 인증서를 사용하지 못함을 의미

인증서 요청

다음 이미지와 같이 인증서 요청을 AWS Console 을 통해 요청을 한다. boong.dev 도메인은 필자가 Google Domains 를 통해 구입한 외부 도메인이며 .dev 도메인의 경우 AWS Route53 에서 지원하지 않고 있다. 도메인 등록은 이전 게시글에서 확인 가능합니다. [AWS] Route 53 외부 도메인 적용 검증 대기 중인 인증서 안으로 들어가서 Route S3에서 레코드 생성 버튼을 눌러 둘다 등록해 준다

Route 53 을 사용하므로 Reoute 53 에 CNAME 을 등록하여 검증하며

외부 네임 서버를 이용시에는 외부 네임 서버에 해당 CNAME 을 등록하여 검증을 마쳐야 인증서가 정상적으로 등록 된다. 정상적으로 발급된 모습

AWS Route 53 에서 지원하는 최상위 도메인 중에서 내가 원하는 .dev 도메인은 존재 하지 않았다. 그러면 어떻게 해야하나? 외부에서 도메인을 사서 등록하여 사용하는 방법이다.

Google Domains 에서 계속 눈독 들여왔던 도메인을 구입

보시다시피 .dev 도메인은 보안 네임스페이스로 사용시 반드시 SSL 인증서가 필요하다. 즉 HTTPS 통신을 해야만 한다.

구입한 도메인을 이제 AWS Route 53 에 등록하여야 한다

Route 53 호스팅 영역 생성

나중에 라우팅 대상 값 모자이크 처리

라우팅 대상값을 맞춤 네임서버에 등록 전환되는 데에는 시간이 걸린다

• 위 Diagram 중 S3 Bucket 정적 웹 사이트 호스팅과 EC2-RDS 연결까지 진행

S3 static web hosting

React 기반으로 작성된 Front 를 Build 하여 S3 bucket 에 업로드 한다.

• 단, build 폴더로 업로드시 경로가 꼬일 수 있으니 조심

Bucket 의 속성에서 정적 웹 사이트 호스팅 편집

정적 웹 사이트 호스팅 설정, 리액트의 인덱스 문서 index.html 지정 등

Bucket 의 접속 정책 생성

S3 정적 웹 사이트 접속

Trouble Shooting

npm run build 시 에러

ERR_OSSL_EVP_UNSUPPORTED

ERR_OSSL_EVP_UNSUPPORTED

해당 에러는 모듈 중 하나 혹은 일부가 Node 17.x 부터 적용된 OpenSSL 3 버전의 규격에 맞지 않을 경우 발행 할 수 있다.

최하단을 보면 Node.js v18.15.0 으로 자신의 Node 버전을 확인 할 수 있다.

해결 방안

필자가 사용한 방법으로 다음 명령어를 사용하였다

npm audit fix --force

모듈의 버전업으로 문제를 해결하는데 어떤 모듈의 버전인지 확인하기 어렵고 번거롭기 때문이다. 문제된 모듈은 react-scripts 2.0.1 이었으며 업그레이드 후 문제가 해결되었다

• 업그레이드 불가의 경우
  • 노드 버전의 다운그레이드다. 이전 버전의 노드 버전을 설치후 사용하면 된다.
  • 다음 명령어로 openssl legacy 옵션을 설정하여 사용할 수 있다.
    • react-scripts --openssl-legacy-provider start

출처: https://ongamedev.tistory.com/484

Module not found: Error: Can’t resolve ‘fs’ in ../../../dotenv/lib

dotenv 모듈에서 사용하는 fs 를 못찾는다는데 react 는 기본 dotenv 를 내장하고 있는데 내장 dotenv 를 찾는게 아니라 직접 dotenv 를 끌고오는 코드가 있어서 상단

import dotenv from "dotenv"
dotenv.config()

또는

require('dotenv').config();

삭제해준다

Server Setting

필요 프로그램 설치

git

sudo apt-get install git

node

sudo apt-get install nodejs

npm

sudo apt-get install npm

백그라운드 실행

nohup 사용

pm2 사용

Installing

sudo npm install pm2 -g

Running

pm2 --name HelloWorld start npm --start

Listing running processes

pm2 ps

Stopping

pm2 delete 0

Checking logs

pm2 logs

세팅 결과

서버 세팅 완료

클라이언트와 서버가 연결된 모습

Trouble Shooting

Git clone 시 에러

ec2 는 기존에 사용하던 머신이 아닌 새로운 가상 컴퓨터 이므로 등록을 다시 해줘야한다.

ssh-keygen -b 4096 -C "[github 이름] [github 이메일]"

~/.ssh/id_rsa.pub 의 내용을 붙여 쓴다

다른 방법으로 http 로 clone

git clone https://github.com/cs-devops-bootcamp/sprint-aws.git

입력 시 username 과 password 입력을 요구한다 여기서 password 에 Repository Read Token 을 입력해준다

• 발급은 깃허브 깃허브 프로필의 셋팅 → developer setting → personal access → 레포 읽기 토큰 발행 → 복사 후 입력
• username : 깃허브 유저네임

Error: listen EACCES: permission denied 0.0.0.0:80

server code 확인시

포트 번호를 80번으로 사용하는데 실행시키면

Error: listen EACCES: permission denied 0.0.0.0:80 에러가 발생 해당 에러는

1024 이하 포트 번호 즉, well knows port 를 사용하려면 root 권한이 필요하고 node 는 해당 80번 포트에 대한 접근권한이 없다는 의미이다

해결 방안

• sudo 사용 : 안됨

  • node를 root권한(sudo ...) 으로 실행시키면 당연히 안된다. 프로젝트 내에 노드모듈이 아니라 root의 노드모듈을 가져다 쓰기 때문임.

• 폴더와 폴더의 하위 모든 파일을 root 로 권한 변경

  • 리눅스에서 기본적으로 1024번 미만의 TCP/IP 포트 번호는 일반 사용자가 사용할수 없다. 기본적으로 ubuntu의 계정으로 git pull을 받았기 때문에 서버 폴더와 해당 폴더의 모든 파일의 소유자가 ubuntu 였다.

• apache나 nginx 등을 이용해서 80번 포트로 받고 해당 내용을 node.js 쪽으로 전달 해주시면 될 것 같습니다.

• iptables 를 통한 포트 우회

  • 포트 80을 사용하지 말고 8080과 같은 다른 포트에서 실행하고, 아래 명령으로 80을 해당 포트로 리디렉션 해서 사용하시거나...

    sudo iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

  • iptables 초기화

    • 모든 chain에 설정된 모든 rule을 제거합니다.

      iptables -F

    • 기본 chain을 제외한 나머지 모든 chain에 설정된 모든 rule을 제거합니다.

      iptables -X

  • 기본 조회입니다. 설정 상태를 볼 수 있다

    iptables -L- 기본 조회 , iptables -L -v - 상세조회

  • 포트 포워딩 확인 할려면 해당 명령어 사용해서 조회

    • sudo iptables -t nat -L --line-numbers

  • 포트 포워딩 삭제하는 명령어

    • sudo iptalbes -t nat -D PREROUTING [number]
    • ex) sudo iptables -t nat -D PREROUTING 1

RDS

퍼블릭 액세스는 나중에라도 꼭 차단을 하길 바란다.

VPC Peering

VPC Peering이란 서로 다른 VPC간 통신이 가능하도록 연결하는 것을 말합니다. 서비스 구분이나 관리 목적에 따라 VPC 를 구분해 놓았을 때 VPC 간 통신이 필요할 때 사용합니다

목표

여기서는 EC2 - RDS 간의 VPC 를 따로 두고 RDS 의 퍼블릭 액세스를 차단하기 위함입니다

이렇게 하였을 때 RDS 는 연결된 VPC 안 EC2 인스턴스를 통해서만 액세스 가능해지고 다른 VPC 를 가진 서비스에서도 VPC Peering 을 통해 Database 에 접근이 가능할 수 있도록 구성이 가능해 집니다.

특징

• 다른 계정간 생성 가능
• 다른 리전간 생성 가능
• 둘 다 가능

주의점

• VPC 간의 CIDR 대역이 겹치면 안된다
  • 192.168.10.0/24 대역과 192.168.10.0/16 대역을 갖고 있는 VPC 간에는 Peering 자체가 불가능하다
• VPC Peering 이후 각 VPC 간 실제 통신을 위해서는 VPC 의 Route Table 에서 별도의 설정 필요
  • Route Table : VPC 의 서브넷들이 어떻게 동신되는지 정의해 놓은 테이블이다

요약

VPC Peering 은 각각 다른 VPC 와 다른 CIDR 대역간의 연결을 위해 사용한다.

VPC A(요청자) - VPC B(수락자) 를 연결하여 통신이 가능하게끔 만듭니다

A 와 B 가 바뀌어도 상관없지만, 수락자의 계정 또는 리전에서 요청을 수락하여야 VPC Peering 이 완료됩니다.

Route Table 설정

VPC Peering 을 생성해 VPC 간 네트워크 연결할 준비는 끝마쳤다.

이제 VPC Peering 을 사용하여 두 VPC 간의 연결을 하기 위해 Route Table 을 설정해줘야 한다.

EC2 인스턴스의 라우팅 테이블의 정보이다

• 0.0.0.0/0 - igw-0d28... : 인터넷 게이트웨이와 연결되어 인터넷을 사용가능하게 라우팅 된것
• 172.31.0.0/16 - local : local 연결이다

이제 여기에 대상 VPC 의 CIDR 과 VPC ID 를 연결하고 서브넷 연결 또한 명시해주면 VPC 간의 통신이 이루어진다.

EC2 에서 RDS 로의 데이터 요청이므로 RDS 쪽에만 라우팅해주면 된다.

양방향 통신의 경우 양쪽다 설정해주면 된다.

RDS 는 당연히 보안그룹에서 인바운드 규칙으로 허용해주어야 한다.

결과

EC2 : Elastic Compute Cloud

AWS 에서 제공하는 클라우드 컴퓨팅 서비스로

AWS 에서 원격으로 제어 가능한 가상의 컴퓨터를 한 대 빌리는 것이다

이 가상의 컴퓨터로 서버, 스토리지, 데이터베이스 등의 작업을 할 수 있다

Elastic : 탄력(신축성)있는, 유연한

이점

• 구성하는데 필요한 시간이 짧다
• 다양한 운영체제에 대한 선택이 가능하다
  • AMI 라는 다양한 템플릿을 제공한다
  • AMI 를 통해서 필요한 용도에 따라 다양한 운영체제에 대한 선택이 가능하다
    • ubuntu, redhat, ms, Linux 등
  • CPU 와 RAM, 용량까지도 손쉽게 구성 가능하다
• 사용한 만큼 지불하여서 저렴하다
• 사용자가 인스턴스를 완전히 제어 가능하다
• 보안 및 네트워크 구성, 스토리지 관리에 효과적이다

Instance AWS 에서 빌린 컴퓨터를 Instance 라 한다 Instance 는 직접 사용하는 컴퓨터와 다르게 아마존이 전 세계에 만들어 놓은 Data Center 에 만들어져 있기 때문에 네트워크(인터넷)를 통해 제어한다는 차이점만 있을 뿐 일반적인 컴퓨터와 다른 점 없다

AWS EC2 Instance 생성 의미

선택한 AMI 를 토대로 운영체제, CPU, RAM 혹은 런타임 등이 구성된 컴퓨터를 빌리는 것

Instance (인스턴스)

Instance (인스턴스)

가상 컴퓨팅 환경으로, 하나의 가상 컴퓨터(서버)라고 생각한다.

인스턴스에서 실행하려는 애플리케이션 또는 소프트웨어에 필요한 메모리 양과 컴퓨팅 파워를 기준으로 인스턴스 유형을 선택한다

인스턴스 유형

AWS 는 각 인스턴스의 사용 목적 (서버용, 머신러닝용, 게임용) 에 따라 타입별로 인스턴스에 이름을 부여해 구분 하고 있다.

인스턴스 유형은 다음으로 쪼개져 있다

• 범용
• 컴퓨팅 최적화
• 메모리 최적화
• 스토리지 최적화
• 액셀러레이티드 컴퓨팅
• 이전 세대 인스턴스 유형

인스턴스 유형은 굉장히 많고 자세한 내용은 다음 Reference 를 통해 알 수 있다

• AWS Docs
• AWS EC2 안내

인스턴스 유형 읽는 법

EC2 Instance Type의 작명 규칙 예시 출처: https://wisen.co.kr/pages/blog/blog-detail.html?idx=12078

• c : 인스턴스 유형 (패밀리) ( c 는 컴퓨팅 최적화 유형이다)

• 5 : 인스턴스 세대

• d : • C5d 인스턴스를 사용하면 로컬 NVMe 기반 SSD가 호스트 서버에 물리적으로 연결되며 C5 인스턴스 수명과 결합된 블록 수준의 스토리지를 제공 한다고 안내 되어있다

• 9xlarge : 인스턴스 사이즈로 xlarge 보다 더 큰 사이즈를 뜻함

  

AMI (Amazone Machine Image)

EC2 인스턴스를 생성할 때 사용하는 소프트웨어 구성이 기재된 템플릿이다

종류로는

• 단순 운영체제(윈도우, 우분투, 리눅스 등)
• 특정 런타임 설치 템플릿 (우분투 + node.js, 윈도우 + JVM 등)
• 커스터마이징된 AMI

등이 있다.

AWS EC2 AMI 선택 화면

EBS(Elastic Block Storage)

인스턴스는 연산에 관한(CPU, 메모리 등) 처리를 하는데, 데이터를 저장하는 역할은 EBS 가 한다고 생각하면 된다.

클라우드에서 사용하는 가상 하드디스크(HDD) 역할이다

EBS 는 EC2 인스턴스에 사용할 영구 블록 스토리지 볼륨을 제공한다

단 몇분 내에 사용량을 많게 또는 적게 확장할 수 있으며, 프로비저닝 (빌리는 행위) 한 부분에 대해서만 저렴한 비용을 지불 할 수 있다

볼륨 유형 타입

총 5가지 타입을 제공한다.

• 범용 (General Purpose of GP3) : SSD
• 프로비저닝 된 IOPS (Provisioned IOPS or io2) : SSD
• 쓰루풋 최적화 (Throughput Optimized HDD or st1)
• 콜드 HDD (SC1)
• 마그네틱 (Standard)

AWS 볼륨 유형 안내는 다음과 같다

• SSD 볼륨

  

• HDD 볼륨

  !

• 이전 세대 볼륨

인스턴스의 라이프 사이클

Amazon EC2 인스턴스는 시작한 순간부터 종료될 때까지 다양한 상태로 전환된다

AWS EC2 라이프 사이클 출처: aws

• 밑으로는 더 공부하기 더 자세하게

  인스턴스 구입 옵션

Amazon EC2는 사용자가 요구 사항에 따라 비용을 최적화할 수 있도록 다음과 같은 구입 옵션을 제공

• 온디맨드 인스턴스 - 시작하는 인스턴스에 대한 비용을 초 단위로 지불합니다.
• 절감형 플랜(Savings Plans) - 1년 또는 3년 기간 동안 시간당 USD로 일관된 사용량을 약정하여 Amazon EC2 비용을 절감할 수 있습니다.
• 예약 인스턴스 - 1년 또는 3년 기간 동안 인스턴스 유형 및 리전을 포함하여 일관된 인스턴스 구성을 약정하여 Amazon EC2 비용을 절감할 수 있습니다.
• 스팟 인스턴스 - 미사용 EC2 인스턴스를 요청하여 Amazon EC2 비용을 대폭 줄일 수 있습니다.
• 전용 호스트 - 인스턴스 실행을 전담하는 실제 호스트 비용을 지불하며, 기존의 소켓, 코어 또는 VM 소프트웨어별 라이선스를 가져와 비용을 절감합니다.
• 전용 인스턴스 - 단일 테넌트 하드웨어에서 실행되는 인스턴스 비용을 시간 단위로 지불합니다.
• 용량 예약 - 원하는 기간 동안 특정 가용 영역의 EC2 인스턴스에 대해 용량을 예약합니다.

네트워킹 - Instance IP 주소 지정

프라이빗 IPv4

프라이빗 IPv4 주소는 인터넷을 통해 연결할 수 없는 IP 주소입니다.

프라이빗 IPv4 주소는 동일 VPC에서 인스턴스 간의 통신을 위해 사용합니다. 인스턴스를 시작할 때 인스턴스에 기본 프라이빗 IPv4 주소와 내부 DNS 호스트 이름이 할당됩니다.

퍼블릭 IPv4

퍼블릭 IP 주소는 인터넷을 통해 연결할 수 있는 IPv4 주소입니다.

퍼블릭 주소는 인스턴스와 인터넷의 상호 통신을 위해 사용될 수 있습니다. 인스턴스가 중지되거나 최대 절전 모드로 전환되거나 종료되면 인스턴스의 퍼블릭 IP 주소는 해제됩니다. 중지되거나 최대 절전 모드로 전환된 인스턴스가 시작되면 새 퍼블릭 IP 주소가 할당됩니다. 따라서 필요에 따라 인스턴스 간에 연결할 수 있는 영구 퍼블릭 IP 주소가 필요한 경우 탄력적 IP(Elastic IP) 주소를 대신하여 사용합니다.

Elastic IP

탄력적 IP 주소는 동적 클라우드 컴퓨팅을 위해 고안된 정적 IPv4 주소입니다.

탄력적 IP 주소는 AWS 계정에 할당되며 해제할 때까지 할당된 상태로 유지됩니다. 탄력적 IP 주소를 사용하면 주소를 계정의 다른 인스턴스에 신속하게 다시 매핑하여 인스턴스나 소프트웨어의 오류를 마스킹할 수 있습니다. 또는 도메인이 인스턴스를 가리키도록 도메인에 대한 DNS 레코드에 탄력적 IP 주소를 지정할 수 있습니다. 주의해야 할 점은 연결 해제한 탄력적 IP 주소는 명시적으로 릴리스할 때까지 계정에 할당되어 있습니다. 따라서 실행 중인 인스턴스와 연결되지 않은 탄력적 IP 주소에 대해서는 소액의 시간당 요금이 부과됩니다.

Docker Compose는 Dockerized 애플리케이션을 정의하고 실행하기 위한 도구입니다.

여러개의 컨테이너를 정의하고 실행하기 위한 YAML 파일로 작성됩니다.

Dockerized란 Docker 컨테이너 내에서 실행되는 애플리케이션 또는 서비스를 의미합니다. 즉, Docker 컨테이너를 사용하여 애플리케이션을 패키징하고, 배포하며 실행하는 것을 의미

Docker Compose 설치

Docker docs 에서 가장 권장하는 방법은 Docker Desktop 을 설치하는 것이다

Docker Desktop 이 설치되어진 경우 말고 Docker Engine 및 Docker CLI 가 이미 설치되어 있는 경우는 다음과 같다

저장소를 사용하여 설치 하는 경우

1. 저장소를 설정하여야 한다. 저장소 설정의 경우 다음 링크를 통해 확인

   우분투 | 센트OS | 데비안 | 페도라 | RHEL | SLES .

2. 패키지 인덱스를 업데이트 및 최신 버전의 Docker Compose 설치

    # Ubuntu 기준 설명
    $ sudo apt-get update
    $ sudo apt-get install docker-compose-plugin

3. 버전을 확인 Docker Compose 설치 확인

    $ docker compose version

플러그인 수동 설치

1. Compose CLI 플러그인을 다운로드하고 설치

    DOCKER_CONFIG=${DOCKER_CONFIG:-$HOME/.docker}
    mkdir -p $DOCKER_CONFIG/cli-plugins
    curl -SL https://github.com/docker/compose/releases/download/v2.17.2/docker-compose-linux-x86_64 -o $DOCKER_CONFIG/cli-plugins/docker-compose

2. 바이너리에 실행 권한 적용

    chmod +x $DOCKER_CONFIG/cli-plugins/docker-compose
    # 또는 모든 사용자를 위한 Compose 설치
    sudo chmod +x /usr/local/lib/docker/cli-plugins/docker-compose

3. 설치 확인

    $ docker compose version

Docker Compose

Docker Compose 의 최신 버전은 2023년 6월 말부터 Compose V1은 더 이상 지원되지 않으며 모든 Docker Desktop 버전에서 제거됨으로 Docker Compose V2 라고 봐도 무방하다.

Docker Compose V2 의 경우 명령어에서 변화가 있어 알아 두어야 한다.

docker-compose up
# v1 에서의 사용 명령어
docker compose up
# v2 에서의 사용 명령어 

Docker Compose YAML 파일 작성하기

Docker Compose YAML 파일을 작성해서 Docker Compose 를 사용할 준비를 합니다. 이 파일은 여러 개의 컨테이너를 정의하고 각 컨테이너가 실행되는 방식을 설정합니다.

# Docker Compose YAML 파일의 예시
version: "3.9"

services:
  web:
    build: .
    ports:
      - "5000:5000"
    volumes:
      - .:/code
    depends_on:
      - redis
  redis:
    image: "redis:alpine"

• version : Compose 파일의 버전
• services : 컨테이너들의 설정을 정의
• 위 예시에서는 web과 redis라는 두 개의 컨테이너를 정의
  • 각각의 컨테이너 이미지 이름
  • Dockerfile 위치
  • 포트 포워딩,
  • 볼륨 마운트
  • 다른 컨테이너에 대한 의존성이 정의

사용 명령어

• 실행

  Docker Compose YAML 파일을 작성한 후 해당 디렉토리에서 다음 명령어 사용

    $ docker compose up
    # Docker Compose YAML 파일에서 정의된 모든 컨테이너를 빌드하고 실행한다
    # 기본적으로 docker-compose.yml 파일을 찾는다
    # -d detech 옵션을 사용하여 백그라운드 실행 가능
  
    # 특정 다른 이름의 파일을 사용해야 할 경우
    # -f 또는 --file 옵션을 사용 docker compose 가 사용할 파일 이름 지정
    $ docker compose -f docker-compose-dev.yml up
    # 여러번 사용하여 파일 추가 가능
    $ docker compose -f docker-compose.yml -f docker-compose.dev.yml up

• 중지

  Docker Compose를 중지하려면 다음과 같이 docker-compose down 명령어를 사용합니다.

    $ docker compose down
    # docker compose 실행 중인 모든 컨테이너를 중지하고, 컨테이너, 네트워크 및 볼륨과 같은 모든 Docker 자원을 삭제

• Docker Compose 로 관리할 수 있는 컨테이너 확인

    $ docker compose ps
    # yml 없으면 나오는 경고문
    # no configuration file provided: not found

• ※ 주의

  • docker compose 모든 명령어는 docker compose 설정 파일이 있는 디렉토리에서 사용

도커 클라이언트 명령어

도커 이미지의 내부 파일 구조 보기

• docker run ls
  • 명령어 진행 순서
    1. 이미지를 이용해 컨테이너 생성
    2. 이미지 안에 들어 있는 파일 스냅숏(bin, dev, etc 등 : 리눅스 커널 디렉토리 부터 다양한 파일과 프로그램들) 이 컨테이너 안에 있는 하드디스크로 다운로드
    3. 이미지 이름 뒤에 다른 명령어를 추가했기 때문에( ls ) 원래 이미지에 들어 있는 기본 명령어는 무시되고 ls 명령어가 실행되어 파일 구조를 확인할 수 있다.
  • 주의 : 모든 도커 이미지에서 ls 명령어를 실행 할 수 있는 것이 아닌 ls 명령어를 사용할 수 있는 파일이 들어 있는 경우 사용가능하다. 다른 명령어 또한 마찬가지이다.

컨테이너 나열하기

• docker ps

  • ps = process status 약자이다.

  • 실행중인 도커 컨테이너를 나열하여 보여주는 명령어이다.

  • 출력 항목

    • CONTAINER ID : 컨테이너의 고유한 아이디 해시값, 실제로는 더 길지만 일부분만 출력, 중복이 안된다 (해시값이니깐)
    • IMAGE : 컨테이너 생성 시 사용한 도커 이미지 이름
    • COMMAND : 컨테이너 시작 시 실행될 명령어, 대부분 이미지에 내장되어 있어 별도 설정이 불필요 하다.
    • CREATED : 컨테이너가 생성된 시각
    • STATUS : 컨테이너의 상태, 실행 중 = Up, 종료 = Exited, 일시 정지 = Pause
    • PORTS : 컨테이너가 개방한 포트와 호스트에 연결한 포트, 특별한 설정을 하지 않은 경우 출력되지 않는다
    • NAMES : 컨테이너의 고유한 이름, 컨테이너 생성시 --name 옵션으로 이름을 설정하지 않으면 도커 엔진이 임의로 형용사와 명사를 조합해 설정, id와 마찬가지로 중복이 안된다. dorcer rename <원래이름> <변경할 이름> 명령어 사용으로 이름을 변경할 수 있다.

    원하는 항목만 보기

  • docker ps --format 'table {{.Name}} \t table {{.Image}}' 와 같이 쓴다.

    모든 도커 컨테이너를 나열

  • docker ps -a

도커 컨테이너의 생성과 실행

도커 컨테이너에는 생명 주기가 있다. 다음 생명 주기 별 명령어를 알아보겠다./

생성 → 시작 → 실행 → 중지(재시작 가능한 상태) → 삭제

도커 컨테이너를 생성하고 실행하기

• docker run <이미지 이름>
  • 두 개의 명령어가 합쳐진 명령어이다.
    • docker create <이미지 이름> : 도커 이미지를 이용해 도커 컨테이너를 생성
      • 이미지 안 파일들을 도커 컨테이너의 하드디스크로 다운
    • docker start <컨테이너 ID/이름> : 생성된 도커 컨테이너 시작해서 실행
      • 이미지 안에 있는 시작 시 실행할 명령어 컨테이너 안에서 작동시킨다.
      • docker start -a <컨테이너 ID/이름>
        • -a 옵션 : attach 의 약자로 컨테이너를 실행한 후에 표준 입력(stdin), 표준 출력 (stdout), 표준 에러(stderr)를 가능하게 하고, 프로그램으로 입력 받은 내용을 터미널에 포여주는 역할을 하는 옵션

도커 컨테이너 멈추기

• docker stop <중지할 컨테이너 ID/이름> or docker kill <중지할 컨테이너 ID/이름> 두 가지 명령어 사용
• 차이점
  • docker stop 은 Graceful(우아하게)하게 컨테이너를 중지시킨다.
    • Graceful 하다 == 하고 있던 작업들을 모두 마치고 컨테이너를 중지시키는 것을 뜻함
    • docker stop 명령어는 SIGTERM 이라는 것을 보내 진행 중인 프로세스를 정리하는 시간(Grace Period)을 갖게한 다음에 SIGKILL을 보내서 컨테이너를 중지 시킨다.
  • docker kill 은 어떠한 것도 기다리지 않고 즉시 컨테이너를 중지시킨다.
    • docker kill 은 SIGTERM 없이 SIGKILL 을 보내서 모든 프로세스를 멈추고 컨테이너를 중지 시킨다.

도커 컨테이너 삭제하기

• docker rm <중지할 컨테이너 ID/이름>
  • 주의 : 삭제할 때에는 컨테이너가 중지된 상태여야 한다. 실행중이라면 오류 발생

중지된 모든 컨테이너 삭제하기

• docker rmdocker ps -a -q: `'` 홑 따옴표 아니다. (그레이브)` 이거다

도커 이미지 삭제하기

• docker rmi <이미지 ID>

사용하지 않는 데이터 삭제하기

• docker system prune

실행 중인 컨테이너에 명령어 전달하기

• docker exec <컨테이너 ID> <명령어>
  • 이미 실행중인 도커 컨테이너에 명령어를 보낸다.

레디스를 이용해 도커 컨테이너 이해

docker run redis 로 레디스 서버 실행

redis-cli 로 레디스 클라이언트 실행

레디스 클라이언트 → 명령어 실행 set value1 hello → 레디스 서버

하지만 redis-cli 명령어로 레디스 클라이언트를 실행하면 에러가 난다.

• 이유는?
  • 레디스 클라이언트 실행 redis-cli : 실행하려 하지만 도커 컨테이너 밖이라 실행이 안된다.
  • 도커 컨테이너 [ 레디스 서버 - 동작 중 ]
• 해결은?
  • 도커 컨테이너 [ 레디스 클라이언트 → 레디스 서버 ] : 도커 컨테이너 안에서 실행하는 방법으로 해결해야 한다.
  • 도커 컨테이너 안에서 레디스 클라이언트를 실행하기 위해 앞에서 배운 exec 명령어를 사용한다
  • docker exec -it <레디스 컨테이너 ID> redis-cli
    • 여기서 -it 옵션은?
    • -i : interactive
    • -t : terminal
    • -it 옵션이 없으면 redis-cli 를 실행과 동시에 종료된다.
  • 레디스 클라이언트가 실행되고 명령어를 칠 수 있게 된다 set key1 hello, → get key1

실행 중인 컨테이너에서 터미널 사용하기

• docker exec -it sh <컨테이너 ID> sh
• 매번 docker exec -it <컨테이너 ID> <명령어> 명령어로 모두 입력하는 것은 비효율적인 작업이다. 비효율적인 면을 해결하기 위해 사용한다.
• 도커 컨테이너에 셸이나 터미널 환경으로 접속해 사용하는 명령어
• Ctrl + D 로 셸이나 터미널 환경에서 나올 수 있다.

도커와 컨테이너

AWS 에서의 도커 정의:

• Docker는 애플리케이션을 신속하게 구축, 테스트 및 배포할 수 있는 소프트웨어 플랫폼입니다. Docker는 소프트웨어를 컨테이너 라는 표준화된 유닛으로 패키징하며, 이 컨테이너에는 라이브러리, 시스템 도구, 코드, 런타임 등 소프트웨어를 실행하는 데 필요한 모든 것이 포함되어 있습니다. Docker를 사용하면 환경에 구애받지 않고 애플리케이션을 신속하게 배포 및 확장할 수 있으며 코드가 문제없이 실행될 것임을 확신할 수 있습니다.

위키피디아에서 제공하는 도커의 정의:

• (Docker)는 리눅스의 응용 프로그램들을 프로세스 격리 기술들을 사용해 컨테이너로 실행하고 관리하는 오픈 소스 프로젝트이다.

둘 모두 도커에 대해서 자세히 알기 어렵지만 컨테이너라는 개념이 나온다.

컨테이너

실생활에서의 컨테이너는 반복 사용 가능한 상자모양의 큰 수송 용기 물건을 담는 용도이다.

도커에서의 컨테이너

실세계에서 무언가를 담는 것처럼 도커에서의 컨테이너는 다양한 프로그램과 실행 환경을 컨테이너에 담고, 동일한 인터페이스를 제공하여 프로그램의 배포 및 관리를 단순하게 한다.

도커 이미지와 도커 컨테이너

도커 컨테이너를 만들기 위해서는 도커 이미지가 필요하다.

둘 정의

• 도커 컨테이너 : 코드와 모든 종속성을 패키지화하여 응용 프로그램이 한 컴퓨팅 환경에서 다른 컴퓨팅 환경으로 안정적으로 실행되도록 하는 소프트웨어 표준이다.
• 도커 이미지 : 코드, 런타임, 시스템 도구, 시스템 라이브러리 및 설정과 같은 응용 프로그램을 실행하는 데 필요한 모든 것을 포함하는 가볍고 독립적이며 실행 가능한 소프트웨어 패키지이다.

도커 이미지를 이용해 여러 개의 도커 컨테이너를 만들 수 있다. 이때 도커 컨테이너를 도커 이미지의 인스턴스라고 부른다.

도커를 사용할 때의 흐름

1. 도커 클라이언트(CLI) 에 원하는 명령을 위한 명령어를 입력

2. 도커 서버(도커 데몬)가 도커 클라이언트에 입력한 명령어를 전달받으면 명령어에 따른 이미지를 생성하고, 컨테이너를 실행한다. 그리고 해당 컨테이너에서 애플리케이션을 실행한다

   1. 간단한 도커 사용

   2. hello-world 라는 프로그램을 도커 환경에서 실행한다. 이미지의 이름이 hello-world이다.

      docker run hello-world

   hello-world 프로그램 도커 내부 처리 과정

   1. 도커 클라이언트에 명령어를 입력하면 클라이언트에서 도커 서버로 요청
   2. 서버에서 hello-world 라는 이미지가 로컬에 이미 다운로드 되어 있는지 확인
   3. 이미지가 있으면 5번으로 없으면 Unable to find image 'hello-world:latest' locally' 문구 출력
   4. 도커 이미지가 저장된 도커 허브(Docker Hub)에서 hello-world 이미지를 가져오고, 로컬에 저장 후 보관한다. (이미지 캐시 보관 장소)
   5. hello-world 이미지를 이용해서 컨테이너를 생성
   6. 생성된 컨테이너는 이미지에서 받은 설정이나 조건에 따라 프로그램을 실행한다.

도커와 기존 가상화 기술의 차이점

가상화 기술 이전 서버

하나의 서버, 하나의 운영체제, 하나의 프로그램만을 운영하여 안정적이지만 사용하지 않는 공간이 많아 비효율적

하이퍼바이저 기반의 가상화 기술

논리적으로 공간을 분할하여 가상 머신(VM) 이라는 독립적인 가상 환경에서 서버를 이용하는 기술을 이용해, 한 대의 서버로 여러 프로그램을 운영가능하게 되며 비효율적인 부분 해결.

하이퍼바이저는 호스트 시스템에서 다수의 게스트 운영체제(OS) 를 구동할 수 있게 해주는 소프트웨어이며, 하드웨어를 가상화하면서 하드웨어와 각각의 가상 머신(VM) 을 모니터링하는 중간 관리자이기도 하다.

하이퍼 바이저의 종류

• 하이퍼바이저
  • 네이티브 하이퍼바이저
    • 구성
    • 하드웨어 → 하이퍼바이저 → OS
  • 호스트형 하이퍼바이저
    • 구성
    • 하트웨어 → OS → 하이퍼바이저 → OS

네이티브 하이퍼바이저 (bare metal, MS Azure 에서 사용하는 방식)

• 하이퍼바이저가 직접 하드웨어를 제어하기 때문에 자원을 효율적으로 사용 가능
• 별도의 호스트OS 가 없어 오버헤드가 적다
• 여러 하드웨어 드라이버를 세팅해야 하므로 설치가 어려움

호스트형 하이퍼바이저

• OS 위에서 실행된다.
• 하드웨어 자원을 VM 내부의 게스트 OS 에 에뮬레이트 하는 방식 == 오버헤드가 크다
• 게스트 OS 종류에 대한 제약이 없고 구현이 쉽다.
• 대다수 많은 사람이 이용하는 VM

도커 컨테이너 는 가상 머신(VM)과 비교했을 떄 하이퍼바이저와 게스트OS 가 필요하지 않기 때문에 가볍다. 호스트 OS 위에 애플리케이션의 실행 패키지인 이미지만 배포하면 끝이다.

가상 머신은 애플리케이션을 실행하기 위해 가상 머신을 실행하고 자원을 할당한 다음, 게스트 OS(무겁다)를 부팅해 애플리케이션을 실행한다. → 훨씬 복잡하고 무겁다.

도커 컨테이너 격리 원리

리눅스의 Cgroup(control groups)과 네임스페이스(namespaces)에 대해 알아야 한다.

Cgroup(control groups)과 네임스페이스(namespaces)

다른 프로세스 사이에 벽을 만드는 리눅스 커널의 기능이다.

??? 도커를 사용하는 개발 환경 중 Windows 와 macOS 가 다수인데 어떻게 도커는 Linux 커널의 기능을 사용하는가?

→ 도커 서버는 리눅스 VM 환경에서 실행되고 있기 때문이다. 따라서 모든 컨테이너가 리눅스 가상 머신에서 생성되며, 리눅스 커널이 컨테이너를 격리시키고 리소스를 나눠주게 된다.

Cgroup

• CPU, 메모리, 네트워크 대역폭, HD I/O 등 프로세스 그룹의 시스템 리소스 사용량을 관리

네임스페이스

• 하나의 시스템에서 프로세스를 격리시킬 수 있는 가상화 기술로 별개의 독립된 공간을 사용하는 것처럼 격리된 환경을 제공하는 경량 프로세스 가상화 기술이다.

도커 컨테이너 구조

호스트 OS 는 공유하지만 하나의 컨테이너는 다른 컨테이너와 격리되며 그 안에서 실행되는 프로세스를 작동시키기 위해 필요한 양에 맞는 디스크, 네트워크, RAM 등이 할당되어 있다.

도커 이미지

도커 이지미는 응용 프로그램을 실행하는 데 필요한 모든 것을 포함한다.

필요한 모든 것

1. 컨테이너가 시작될 때 실행할 명령어
   1. 예) run kakaotalk
2. 파일 스냅숏
   1. 파일 스냅숏은 디렉터리나 파일을 복사한 것

도커 컨테이너 생성되는 순서

1. 도커 클라이언트에 ‘docker run <이미지>’ 명령어 실행
2. 도커 이미지에 있는 파일 스냅숏을 컨테이너에 있는 하드 디스크로 옮긴다. (컨테이너 안에서 애플리케이션을 설치하고 실행해야 하므로 컨테이너로 이동시킨다.)
3. 도커 이미지가 가지고 있는 명령어(컨테이너가 실행될 때 사용할 명령어)를 컨테이너에 전달한다.
4. 컨테이너가 실행될 때 명령어를 이용해 애플리케이션 실행

클라이언트와 서버 사이에서 중계 역할을 수행하는 컴퓨터 시스템이나 응용 프로그램을 말한다.

Proxy 사전적 의미로 ‘대리’ 하는 것을 뜻한다.

이것으로 컴퓨터에서 어떠한 작업을 대신하는 것을 뜻한다.

Proxy Server

프록시 서버는 클라이언트에서 서버로 접속을 할 때 직접적으로 접속하지 않고 중간에 대신 전달하는 서버를 의미한다.

출처 : https://hylog.vercel.app/posts/what-is-proxy

Proxy Server 요청과 응답 과정

과정

• 클라이언트에서 웹 브라우저를 URL 을 입력하여 프록시 서버로 Request 를 보낸다.
• 프록시 서버는 내부에서 설정된 요청받은 URL 과 연결된 웹 서버로 Request 를 보낸다.
• Request 를 받은 웹 서버는 Response 를 보내준다
• 프록시 서버가 Response 를 받고 다시 클라이언트의 웹 브라우저로 Response 를 보낸다.

이점

• 클라이언트와 서버 간의 직접적인 통신을 막음
• 보안강화
• 로드 밸런싱 등의 기능을 수행

Proxy 종류

웹 프록시 (Web Proxy)

• 웹 페이지를 요청하는 클라이언트와 웹 서버 사이에서 중계 역할을 수행
• 웹 프록시는 캐싱을 이용하여 웹 페이지를 빠르게 전송한다.
• 웹 필터링을 통해 사용자가 웹 사이트를 접근하는 것을 제어한다.

리버스 프록시 (Reverse Proxy)

• 웹 서버와 클라이언트 사이에서 요청을 수신하여 이를 내부 서버로 전달한다.
• 보안상 이유로 내부 서버에 직접 접근하지 않고, 외부에서 접근할 수 있는 공개적인 IP 주소를 사용하여 서버를 보호한다.

익명 프록시 (Anonymous Proxy)

• 사용자의 IP 주소를 숨기고, 웹 페이지를 요청하는 클라이언트와 웹 서버 사이에서 중계
• 인터넷 사용자의 개인 정보를 보호하기 위해 사용

투명 프록시 (Transparent Proxy)

• 웹 페이지를 요청하는 클라이언트와 웹 서버 사이에서 중계
• 사용자의 IP 를 숨기지 않음
• 보안상의 이유로 내부 네트워크에 있는 서버에 직접 접근하지 않고 프록시를 거쳐야만 접근하도록 하는 방화벽 역할을 한다.

SOCKS 프록시 (SOCKS Proxy)

• 다양한 프로토콜을 지원하는 프록시
• TCP 및 UDP 데이터를 전송가능
• 사용자 인증 기능 지원

Proxy 의 역할

성능 개선

캐싱

• 이전에 요청한 내용을 캐시하여 동일 요청시 서버에 요청하지 않고 캐시된 데이터를 반환할 수 있다
• 네트워크 병목 현상 해결하고, 응답 속도를 향상시킬 수 있다.

익명화

• 클라이언트 IP 를 가릴 수 있어 익명성 제공
• 개인정보 사용자 프라이버시를 보호

필터링과 접근 제어

• HTTP 요청 및 응답을 필터링하여 접근 제어, 콘텐츠 제한 웹 사용량 제한 등 수행
• 보안 강화와 네트워크 대역폭 절약 효과

보안

• 클라이언트 IP 주소 은닉
• 필터링을 통해 악성 코드나 스팸 차단

부하 분산 (로드 밸런싱)

• 여러 대의 서버에게 클라이언트들의 요청을 분산 시키는 로드 밸런싱 기능을 수행
• 서버의 부하를 분산시켜 서버의 성능을 향상
• 안정적인 서비스를 제공

• 간단하지만 시간이 촉박하다 3일의 시간이 주어지지만 2.5일 느낌
• 기능과 코드의 퀄리티를 높이기 보다는 협업을 중점을 두고 팀원들과 작업하였다
• 미숙한 git 사용법으로 충돌 에러를 많이 보았지만, 경험을 많이 쌓을 수 있었던 거 같기도…
• 설계는 어렵다…🥴

시작한지 얼마 안된 것 같은데 벌써 한달의 시간이 지나가고 있고 첫 번째 프로젝트가 끝났습니다.

• 리눅스 운영체제
• 웹서비스 개발 기초
• Git
• HTTP
• WEB / WAS Server
• 데이터베이스

한달의 시간이 훅 빠져나간 이유인 공부주제들...(많기도 하다🤮)

부트캠프를 수강하기도 전에도 계속 공부해오던 내용이라 적응하는 것에 중점을 둬서 공부했었다. 몰랐던 내용도 알게 되며 아직은 여유가 있었다고 느꼈다

첫 실습 프로젝트

어떤 이유에선지 모르나 어찌저찌 팀장이 되었고, Section1. 프로젝트가 시작되었다. 프로젝트의 주제는 쇼핑몰로 정해졌다

실습 목표

실습의 중요한 목적은 다음과 같다

• API 설계 및 문서를 작성 한다.
• 관계형 데이터베이스를 위한 데이터 모델링을 한다.
• Git 을 이용한 협업을 진행한다.

제작 범위 및 기술 스택

• Javascript
• Fastify
• PostgreSQL
  • ElephantSQL 이용
• ERD 제작
• API 문서 제작

목표는 최소한의 CRUD 기능을 가진 한개의 API 서버를 만드는 것이다. 목표 자체는 그렇게 어렵지 않은 내용이라고 생각하고 나는 중점을 설계와 협업으로 눈을 돌리고 팀원과 작업을 진행하였다.

개발이 끝나고 API 를 사용한 결과 화면

ISSUE

작업을 끝내고 push 하는데에 문제가 생겼다.

힌트 문구를 보았을 때 내 local 과 remote 가 맞지 않기 때문에 git pull 작업을 하고 다시 시도해 보라고 유도해 주고 있다. 작업하던 내용들을 잃어 버리면 안되기에 git stash 로 임시 저장하고 git pull 을 해보았는데…

git pull 조차 안된다. 하지만 치명적인 에러는 아니고 자세히 읽어 보면 설정을 해달라는 말인데.

git pull 방식을 정해 달라는 것이다. .

• 기존 pull

  • 불필요한 merge commit 이 생성 아래 그림의 빨간색 부분

  • 3-way merge 와 비슷하다.

    

• git pull --ff-only
  • fast-forward 관계일 때만 pull을 허용한다.
  • fast-forwad 관계는?
    • 로컬저장소에만 새로운 commit이 있고, 원격저장소에는 없다.
    • 원격저장소에만 새로운 commit이 있고, 로컬저장소에는 없다.
• git pull --rebase
  • 새 브랜치가 시작된 분기점 commit이 존재한다. 이 분기점을 기준 브랜치의 가장 최근 commit으로 변경하는 작업.
  • 로컬 브랜치의 시작점을 원격 브랜치의 마지막 commit으로 옮기는 식인 것 같다. 그 과정에서 conflict가 발생할 경우 이를 해결해줘야 할 듯 싶다.
  • git history가 깔끔해진다는 장점이 있지만, 부주의하게 사용할 경우 별도의 알림 없이 git history를 영구적으로 변경할 수 있기 때문에 ff-only 방식을 더 추천한다고 한다.

git config pull.ff only

위 세가지 방식중 ff 방싱이 추천되므로 명령어로 pull 방식 설정해 주고 다시 실행하였지만

fast-forwad 가 가능하지 않고 중단되었다고 나온다!

강제 PULL

수정 파일 보다 local 의 상태를 conflict 되기 전인 수정 전으로 되돌려야 할거 같아 이번 한 번은 강제적인 방법을 사용하였습니다.

git fetch --all
git reset --hard personal/main
git pull personal main

명령을 통해 수정전 상태로 돌리고 수정파일을 가져온뒤 재 push 하여 해결하였습니다.

강제를 하는 방법이므로 좋은 방법은 아니라고 생각합니다. 가장 좋은 방법은 conflict 된 파일을 찾아서 수정하여 push 를 하거나 stash 를 적극 활용하는 것이 가장 좋은 방법을 아닐까 싶습니다.

마치며

Java 의 SpringBoot 환경에서 공부하던 나에게 생각보다 처음이 많았다.

API 문서를 위한 도구를 사용해보기도 하고, PostgreSQL 을 처음 써보기도 하며

• PostgresSQL 은 마음에 들었다. 조금씩 다른 부분이 있으나 RETURNING 이 있다는게 마음에 들었는지 Postgres 를 향한 첫 인상은 굉장이 좋았다 🤗

Fastify 프레임워크를 처음 다뤄봤다.

• javascript 생태계 답게 굉장히 가볍고 간편한 느낌이 있다. 하지만 처음 사용하는 것이고, 실제 개발 단계는 1일에 가까워서 기능들을 다 활용하지는 못하는 것이 아쉬웠다. Javascript 언어를 잘 알지 못한다는 점도 한 몫했다.(ES6 도 한번은 공부해서 정리하는 게 좋지 않나 하고 생각이 들었다🤔)

처음으로 협업을 하게 되었다.

• 이전에도 같이 협업을 한 경우도 없잖아 있지만, 뭔가 인정하고 싶지 않은 결과물이나 작업이 매우 tiny 한 경우 였기에 이렇게 온전히 팀원들이 있고 git 을 사용해서 협업한 경우는 없기에 감격스러운 정도...😭
• 어떨결에 팀장을 하게 되었지만, 믿음직하지 못한 팀장을 잘 따라와준 팀원들에거 무한한 감사의 박수를 전합니다 👏👏👏

다짐

다음 Section2. 는 Devops 영역의 발을 디딛는 것과 같은 주제들로 짜여있기에 집중해서 Section2 를 진행할 생각이다. 주제들을 듣기만 해도 너무 기대된다. 조금만 적어보자면

• Docker
• AWS
• CI/CD

한 번씩 다 해보았지만 전문적으로 교육을 받아본적이 없이 어깨너머 배워왔던 입장이라 너무 두근두근하다. 잘 배워서 잘 써먹어야지😎

어떤 웹 사이트에 들어갔을 때, 서버가 일방적으로 클라이언트에 전달하는 작은 데이터 조각

• 서버가 웹 브라우저에 정보를 저장하고 불러올 수 있는 수단
• 해당 도메인에 대해 쿠키가 존재하면, 웹 브라우저는 도메인에게 http 요청 시 쿠키를 함께 전달한다.

특징

기본적으로는 쿠키는 오랜 시간 동안 유지될 수 있고, 자바스크립트를 이용해서 쿠키에 접근할 수 있기 때문에 쿠키에 민감한 정보를 담는 것은 위험하다

• 서버가 클라이언트에 데이터를 저장할 수 잇다.
  • 데이터를 저장한 이후 아무 때나 데이터를 가져올 수는 없다.
  • 데이터를 저장한 이후 특정한 조건들이 만족한 경우에만 다시 가져올 수 있다.
  • 이런 조건들은 다음 쿠키 옵션으로 표현

쿠키 옵션

• Domain
  • 쿠키가 전송될 수 있는 도메인을 제한
  • 해당 도메인의 서브도메인에서도 쿠키를 사용
  • 도메인은 포트 및 서브 도메인 정보(www 등) , 세부 경로를 포함하지 않는다.
• Path
  • 쿠키가 전송될 수 있는 URL 경로를 제한
  • 해당 경로와 하위 경로에서만 쿠키를 사용
• MaxAge / Expires
  • 쿠키의 만료 날짜를 지정
  • Expires 는 쿠키가 만료되는 날짜를 GMT 형식으로 지정
  • Max-Age 는 쿠키의 유효 기간을 초 단위로 지정
  • 두 옵션이 모두 지정되지 않는 경우 브라우저 탭을 닫아야만 쿠키가 제거
• Secure
  • HTTPS 연결에서만 쿠키를 전송
• SameSite
  • 쿠키가 외부 사이트로 전송되지 않도록 제한
  • CSRF(Cross-Site Request Forgery) 공격과 같은 보안 위협 방지
• HttpOnly
  • JavaScript를 사용하여 쿠키에 액세스할 수 없도록 한다
  • XSS(Cross-Site Scripting) 공격과 같은 보안 위협에서 쿠키를 안전하게 보호

public IP (공인 IP)

인터넷 사용자의 로컬 네트워크를 식별하기 위해 ISP(인터넷 서비스 공급자)가 제공하는 IP 주소 이다. 공용 IP 주소라고도 불리며 외부에 공개되어 있는 IP 주소이다.

• 공인 IP 는 전세계에서 유일한 IP 주소를 갖는다.
• 외부에 공개되어 있기에 인터넷에 연결된 다른 PC 로부터의 접근가능. 따라서, 공인 IP 를 사용하는 경우 방화벽 등의 보안 프로그램을 설치할 필요가 있다.

private IP (사설 IP)

일반 가정이나 회사 내 등에 할당된 네트워크 IP 주소, 로컬 IP, 가상 IP 라고도 한다. IPv4의 주소 부족으로 인해 서브넷팅된 IP이기 떄문에 라우터에 의해 로컬 네트워크상의 PC 나 장치에 할당된다.

사설 IP 주소 대역

3가지 주소 대역으로 고정

• Class A : 10.0.0.0 ~ 10.255.255.255
• Class B : 172.16.0.0 ~ 172.31.255.255
• Class C : 192.168.0.0 ~ 192.168.255.255

차이점

라우터는 중간에서 public IP 와 private IP 변경해주면서 데이터를 전송해 준다.

터미널 nslookup 결과값

nslookup

nslookup은 name server 관련한 조회를 할 수 있으며, 도메인 이름 서버(DNS)에서 도메인 이름에 해당하는 IP 주소를 찾는 명령어입니다.

코드스테이츠 기본 nslookup 결과값

나타내어지는 정보는 다음과 같다

• 이름 : 검색된 호스트 또는 도메인의 이름
• 검색된 호스트 IP 주소 : 검색된 호스트 또는 도메인의 IP 주소
• 유형 : DNS 레코드 유형, (A, AAAA, CNAME, MX, NS, PTR, SOA, SRV, TXT 등)
  • DNS 레코드 : 도메인 이름과 관련된 정보를 저장하는 데이터베이스 레코드
• TTL : Time To Live 약자, DNS 레코드의 TTL 값을 나타낸다. 레코드가 캐시 될 수 있는 시간을 의미하며, 이 시간이 지나면 DNS 서버는 레코드를 다시 가져와야 한다.
• 서버 : 쿼리를 보낸 DNS 서버의 이름을 나타낸다.
• 로컬 컴퓨터의 DNS 서버 IP 주소 : 쿼리를 보낸 DNS 서버의 IP 주소

nslookup 정밀 모드 사용하여 코드스테이츠 도메인 검색

# nslookup 정밀 모드 사용법
nslookup
set debug
도메인 이름

http://google.com 검색 시 DNS 에서 일어나는 일

DNS

• 웹 사이트에서는 외우기 어려운 IP 주소 대신 도메인 이름을 사용한다.
• 도메인 이름을 실제 네트워크 상에서 사용하는 IP 주소로 바꾸고 해당 주소로 접속하는 과정이 필요
• 이러한 과정, 전체 시스템을 DNS(Domain Name System) 라고 한다.
• 시스템은 전세계적으로 약속된 규칙을 공유
• 상위 기관에서 인증된 기관에게 도메인을 생성하거나 IP 주소로 변경할 수 있는 권한 을 부여한다.
• DNS 는 이처럼 상위 기관과 하위 기관 같은 계층 구조를 가지는 분산 데이터베이스 구조이다.

DNS 구성 요소

• 도메인 네임 스페이스 (Domain Name Space)

  • 도메인 주소 구조

    

    • 주소 영역을 . 으로 구분 → 라벨 (Lavel)
      • 하나의 라벨 : 최대 63개의 문자 (64byte) 사용 가능
      • 대소문자 구분 없이 알파벳, - 만 가능(ASCII 로 표현)
      • 전체 도메인 주소 최대 크기 : 255 개의 문자 (255byte)
    • 주소 해석은 오른쪽 부터
    • 최상위 주소는 항상 가장 오른쪽에 있는 .(root)

  • 도메인 네임 스페이스에 포함되는 각각의 노드들

    • 루트 도메인
      • 네임 스페이스에서 이름 해석의 출발지 역할을 하는 노드 (서버)
      • 최상위 도메인 서버의 정보를 가짐(http://www.iana.org/domains/root/servers)
      • 전 세계 13개의 원본 root 서버가 존재
    • 최상위 도메인 (Top Level Domain = TLD)
      • 국가 코드 최상위 도메인(ccTLD : country code TLD)
        • .kr, .jp 등
      • 일반 최상위 도메인 (gTLD : global TLD)
        • .net, .com, .org 등
      • ARPA : 역방향 조회 시 사용되는 최상위 도메인
        • in-addr.arpa
    • 2차 도메인 (Second Level Domain, Sub Domain)
      • TLD 하위에서 관리되는 서브 도메인
      • 국가 도메인 하위에 기관 유형에 따른 분류
        • .co (일반회사), .ac (교욱기관), .go (정부기관) 등
    • 서브 도메인 (Sub Domain)
      • 상위 도메인에 소속되는 각 기관 또는 회사별 도메인
        • google, naver 등
    • 하위 노드는 무한정 만들 수 있다. 문자수에는 제한 (255byte)

  • 도메인 → IP 주소 (정방향 조회)

  • IP 주소 → 도메인 주소 (역방향 조회)

    • 특수한 상황 (PTR/SPF 레코드를 이용한 스팸메일 필터링)

• 네임 서버 (Name Server)

  • 도메인 → IP 주소 : 네임 서비스 (Name Service)
  • Resolver (해석기) 로부터 요청받은 도메인 이름에 대한 IP 주소를 다시 Resolver (해석기) 로 전달해주는 역할을 수행
  • Primary, Secondary 서버로 구분된다.
    • Primary : 도메인을 관리하는 주 네임서버
    • Secondary : 주 네임 서버가 고장 등으로 서비스 실패 시 네임 서버 역할 수행

• 리졸버 (Resolver)

  • DNS 요청을 네임 서버로 전달하고, 네임 서버로부터 정보를 받아 클라이언트에게 제공하는 기능 제공

검색시 일어나는 일

DNS 동작 과정

1. Local DNS 에 [http://google.com](http://google.com) 라는 hostname 에 대한 IP 주소를 요청한다. Local DNS 에 도메인에 대한 IP 주소가 있는 경우 바로 응답한다.
2. 없다면 다른 DNS 서버와 통신을 시작한다. 차례대로 최상위 Root DNS 서버에 질의 (DNS Query)
3. .com 을 관리하는 DNS 서버를 응답해준다.
4. Local DNS 는 .com 을 관리하는 DNS 서버에게 질의
5. [google.com](http://google.com) 을 관리하는 DNS 서버를 응답해준다.
6. Local DNS 는 [google.com](http://google.com) 을 관리하는 DNS 서버에게 질의
7. [google.com](http://google.com) 에 대한 IP 주소를 응답해준다.
8. Local DNS 는 [http://google.com](http://google.com) 에 대하여 IP 주소를 캐싱하고 클라이언트에 IP 주소를 알려준다.

출처

https://hanamon.kr/dns란-도메인-네임-시스템-개념부터-작동-방식까지/ https://itsandtravels.blogspot.com/2018/11/dnsdomain-name-system-dns.html https://susoterran.github.io/other/dns/ https://velog.io/@hidaehyunlee/공인Public-사설Private-IP의-차이점 https://m.blog.naver.com/on21life/221364194092 https://www.lesstif.com/system-admin/nslookup-20775988.html chat-gpt

데몬

리눅스 환경에서 시스템이 초기화가 끝난 후 init 이라는 특별한 프로그램에 의해 자발적으로 백그라운드에서 실행되는 프로그램을 의미한다.

멀티태스킹 운영체제에서 사용자가 직접적으로 제어하지 않고, 백그라운드에서 돌면서 여러 작업을 하는 프로그램을 의미한다. ex) Windows OS 의 Service

일반적으로 백그라운드에서 작동하는 프로세스 라는 의미로 통용된다.

리눅스에서 데몬은 syslogd, httpd 와 같이 프로그램 이름 끝에 d 가 붙는다. 상시 실행되며 다음과 같은 일을 함

• 하드웨어 장치 관리
• 보조 기억장치와 디렉토리의 연결(마운트)
• 네트워크를 통한 프로세스간 통신(소켓)
• 애플리케이션 수준의 서비스 제공 → 보통 서비스라고 간략하게 줄여서 부름
  • 같은 프로그램을 지칭할 때 서비스와 데몬으로 번갈아가면서 부를 수 있는데, 운영체제의 관점은 ‘데몬’, 사용자 관점에서는 ‘서비스’ 라고 부를 따름이다.

대표적인 데몬 : Web Server (httpd)

웹 페이지에 접근하고 결과를 얻으려면, 웹 페이지를 제공하는 프로세스가 상시 실행되어야 할 것이고 이러한 프로그램을 웹 서버라고 한다. 일반적으로 백그라운드에서 작동되므로, 데몬이라고 부를 수 있다.

httpd 실습

시나리오

• 간단한 HTML 파일 생성

• curl 유틸리티를 통해 해당 주소로 접속

• 과정 코드

    # index.html 작성
    $ echo "<html><body><h1> 첫 HTML 페이지 </h1></body></html>" > index.html
  
    # 웹 서버 실행, 8888 포트 열기
    $ busybox httpd -h . -p 8888
  
    # 웹 서버 접속
    $ curl http://localhost:8888
  
    # 프로세스 확인 명령을 통해 데몬이 실행중인지를 확인
    $ ps aux | grep httpd
  
    # PID 를 이용해 프로세스를 죽인다
    $ kill -9 PID
  
    # 웹 서버 다시 접속, 실패해야 정상
    $ curl http://localhost:8888

실습 결과

• ※ busybox 란?
  • UNIX 명령해 유틸리티의 기능을 하나의 실행 파일 안에 통합시킨 소프트웨어다
  • 작은 바이너리 속 350 여 개의 기능이 들어가 있어 임베디드 환경에서 많이 사용된다.
  • 작은 용량으로 기능들이 간략화 되어 있어 빠진 기능들이 몇 있다.
  • busybox는 각종 유틸리티를 담은 일종의 “스위스 군용 칼”과 같은 리눅스용 애플리케이션으로, 아주 단순한 기능을 가진 웹 서버(httpd)를 포함하고 있습니다.
  • httpd는 기본적으로 데몬으로 실행되며, 위의 실습처럼 백그라운드에서 돌면서, 목적에 맞는 기능(여기서는 웹 서버의 역할)을 수행합니다.

대표적인 데몬 : cron

cron 데몬은 스케쥴에 따라 명령을 실행하는 도구이다.

cron 실습

시나리오

• 매 분마다 날짜와 시스템 가동시간을 파일에 저장하는 명령을 실행
• 실습 코드

$ crontab -e
# 에디터 선택 대화창이 나온다.

# 에디터 선택 후 에디터가 열리면 맨 아랫줄에 입력
* * * * * echo $(/bin/date) - $(/usr/bin/uptime) >> ~/uptime.log

# 파일을 저장하고 닫는다.

• date 명령의 출력, uptime 명령 출력을 uptime.log 파일에 쌓는다
• * * * * * 는 매 분을 뜻한다.
  • https://crontab.guru/#0_20___* 에서 다양한 예제를 확인할 수 있다.
  • 매 10시 명령 수행은 0 20 * * * 이다
• 💡반드시 crontab 을 초기화 할 것

$ crontab -r
$ crontab -l
no crontab for 사용자이름
# 마지막 줄이 출력되야 정상적으로 초기화 된다.

systemctl : 서비스 관리

데몬 확인하기

systemctl : 모든 데몬의 목록 출력, 서비스 목록만 볼려면 --type=service 옵션 사용 (시스템 관리자들을 보통 서비스에 집중하므로)

별도의 실행 없이 cron.service 가 실행되어진 것을 확인 할 수 있다

systemctl

프로그램과 프로세스

• 프로그램 : 프로그래밍 언어를 사용하여 수행절차를 표현해 놓은 명령어들의 집합. 정적인 상태의 파일
• 프로세스 : 운영체제로부터 메모리를 할당받고 실행 되고 있는 프로그램
  • 하나의 프로그램을 여러 번 실행하면 여러 개의 프로스세(다중 프로세스)가 메모리 상에서 실행된다.

스레드

• 스레드 : 사전적 의미로는 한 가닥의 실. 프로세스 내에서 실제로 작업을 수행하는 주체를 의미한다. 모든 프로세스는 한 개 이상의 스레드가 존재하며 작업을 수행한다. 두 개 이상의 스레드를 가지는 프로세스를 멀티 스레드 프로세스라고 한다.
  • 한 프로세스 내에 스레드가 두 개라면 코드가 실행되는 흐름이 두 개 생긴다는 의미

멀티 스레드

• 멀티 스레드 : 하나의 프로세스 내에서 둘 이상의 스레드가 동시에 작업을 수행하는 것을 의미한다. 또한, 멀티 프로세스는 여러 개의 CPU 를 사용하여 여러 프로세스를 동시에 수행하는 것을 의미한다.
• ※ 멀티 스레드와 멀티 프로세스 차이
  • 둘 모두 여러 흐름을 동시에 수행하는 공통점을 가지고 있다.
  • 멀티 프로세스는 독립적인 메모리를 가지고 별도로 실행되지만, 멀티 스레드는 각 스레드가 속한 프로세스의 메모리를 공유한다는 점이 다르다.
• 멀티 스레드의 장점 : 멀티 스레드는 각 스레드들이 자신이 속한 프로세스의 메모리를 공유해서 시스템 자원의 낭비가 적다. 하나의 스레드가 작업을 할 때 다른 스레드가 별도의 작업을 할 수 있어 사용자와의 응답성도 좋아진다.

프로세스 관리

프로세스 실행 방식

• 포그라운드 방식(foreground)
• 백그라운드 방식(background)

포그라운드 방식

사용자가 명령을 입력하고 이를 해석하여 실행한 뒤 결과를 화면에 출력한다. 사용자는 결과를 확인 한 뒤 다른 명령어를 입력하는 대화식으로 작업을 수행하게 되는 방식이다.

포그라운드 방식으로 처리되는 프로세스를 포그라운드 프로세스라고 한다.

백그라운드 방식

포그라운드 방식의 단점은 한 번에 하나의 명령을 실행하여 동시에 여러 프로세스를 실행하기 어려운 점이다.

백그라운드 방식은 프로세스가 실행되는 동안 뒤에서 다른 프로세스가 실행될 수 있다. 여러 개의 프로세스를 동시에 실행 가능하다.

리눅스에서의 사용

#포그라운드 방식
$ command
$ ping google.com

# 백그라운드 방식 - & 추가
$ command &
$ ping google.com &

# nohup 명령어 (no hang up)
$ nohup command &
$ nohup ping google.com &

여기서 백그라운드 방식은 & 를 붙여서 실행하는데, 백그라운드 실행시 사용자의 터미널 세션이 종료되면 실행중인 프로세스도 종료된다. 사용자 터미널 세션이 종료되어도 프로세스를 실행하고 싶다면 nohup 명령어를 사용한다.

프로세스 목록 확인

• ps

  • 현재 실행중인 프로세스의 목록을 확인 할 수 있다.

    • PID : 프로세스 번호
    • TTY : 프로세스가 실행된 터미널의 종류와 번호
    • TIME : 프로세스 실행 시간
    • CMD : 실행되고 있는 프로그램의 이름(명령)

    

더 자세한 옵션

• UNIX 방식
  • -e : 시스템에서 실행중인 모든 프로세스의 정보를 출력
  • -f : 프로세스의 자세한 정보를 출력
  • -u uid : uid 로 특정한 사용자에 대한 모든 프로세스의 정보 출력
  • -p pid : pid 로 지정한 특정 프로세스의 정보 출력
• BSD 방식
  • a : 터미널에서 실행한 프로세스의 정보를 출력
  • u: 프로세스 소유자의 이름, CPU 사용량, 메모리 사용량 등 상세 정보 출력
  • x : 시스템에서 실행 중인 모든 프로세스의 정보 출력

가장 자주 사용하는 옵션 방식

• ps -ef - UNIX , ps aux - BSD

  • ps -ef 출력 정보
    • UID : 프로세스 실행한 사용자 ID
    • PPID : 부모 프로세스 번호
    • C : CPU 사용량 (%)
    • STIME : 프로세스의 시작 날짜 또는 시간
    • TTY : 프로세스가 실행된 터미널의 종류와 번호
    • STAT : 프로세스 상태
  • ps aux 출력 정보
    • USER : 사용자 계정 이름
    • %CPU : CPU 사용량 (%)
    • %MEM : 물리 메모리 사용량 (%)
    • RSS : 사용하고 있는 물리적 메모리 크리 (kb)
    • VSZ : 사용하고 있는 가상 메모리 크기 (kb)
    • START : 프로세스 시작 시간

• pstree

  • 컴퓨터의 전체 프로세스 구조 확인 명령어

  • 트리구조로 도식화하여 프로세스를 확인할 수 있으며, 부모 관계를 파악할 수 있다.

    

kill - 프로세스 종료

터미널에서 프로그램은 ctrl + c 로 종료할 수 있다. 단축키 사용시 이벤트가 발생되고, 이러한 이벤트를 프로세스에 전달하는 과정이 필요하다. 이 때, 이벤트를 프로세스에 알려주기 위해서 사용하는 것을 시그널(Signal) 이라고 한다.

특정 프로세스에 작업 중지, 실행 종료, 대기, 재시작, 강제 종료 등의 시그널을 전달하기 위해 kill 명령어를 사용한다. kill -l 사용하면 사용할 수 있는 시그널의 종류를 확인 할 수 있다.

주 사용 시그널

• SIGHUP : 재시작
• SIGINT : 실행 중지 = ctrl + c
• SIGKILL : 강제 종료
• SIGTERM : 정상 종료 = 기본 명령
• SIGCONT : 정지된 프로세스 실행
• SIGSTOP : 터미널에서 입력되는 정지 시그널
• SIGTSTP : 실행 정지 후 재실행 대기 = ctrl + z

사용 방법

$ kill -<시그널번호 or 시그널명> %작업번호
$ kill -<시그널번호 or 시그널명> PID

jobs - 백그라운드 프로세스 확인

• 프로세스 상태
  • Runnuing : 실행 중
  • Stopped : 일시 중단 (ctrl + z)
  • Terminated : 강제 종료 (kill 명령)
  • Done : 정상 종료

• [1], [2] 는 작업번호이다.
• + 는 현재 처리되고 있는 작업을 의미, - 다음에 작업할 프로세스를 의미한다.
• 필요하다면 fg %<작업번호> 명령을 통해 포그라운드로 전환 가능

표준 스트림(Standard Stream)

• 스트림(Stream) 이란?
  • 프로그램이 드나드는 데이터를 흐름으로 표현한 단어
  • 종류
    • 입력 스트림(Strandard input, STDIN, 0)
    • 출력스트림(Standard output, STDOUT, 1)
    • 오류 메시지 출력 스트림(Standard Error, STDERR, 2)
  • 실제 리눅스의 /dev 디렉토리에서 위 세 개의 표준 스트림을 앞서 언급한 파일 형태로 담고 있다.
• stdin
  • 표준 입력은 프로그램으로 들어가는 입력값의 데이터(보통은 문자열) 스트림이며, Standard Input 을 줄여서 stdin 으로 표현한다.
  • 리눅스 쉘에서 표준 설정은 키보드이다.
  • 모든 프로그램에서 입력을 요구하지 않으며, 대표적인 예로 비밀번호를 입력할 때 표준 입력 스트림을 사용한다.
• stdout
  • 표준 출력은 프로그램이 출력 데이터를 기록하는 스트림으로, Standard Output 을 stdout 으로 줄여 표현한다.
  • 표준 출력은 텍스트 터미널에서 이루어지며, 표준 입력과 마찬가지로 모든 프로그램이 출력을 요구하는 것은 아니다.
• stderr
  • 표준 오류는 프로그램이 오류 메시지나 진단을 출력하기 위해 일반적으로 쓰이는 또다른 출력 스트림이다.
  • Standard Error 를 줄여 stderr 로 줄여 표현한다.

파일 디스크립터 (file descriptor)

리눅스의 모든 파일을 관리하는 방식

명령어 실행 (컴퓨터에게 작업을 요청 -> 프로세스 생성)

• 실제 프로그램을 실행시키는 작업
• 이러한 프로그램은 파일로 존재
• 파일을 실행 시키기 위해서는 먼저 파일을 열어야 한다.
• 파일이 열리면 커널이 해당 프로세스가 동작하는데 필요한 장치나 파일을 번호를 붙여 관리하며, 이러한 번호를 파일 디스크립터 테이블에 저장
• 자주 사용하는 장치들은 미리 번호가 예약되어 있다.

파이프라인과 리다이렉션

리다이렉션(Redirection)

리눅스에서는 세 개의 표준 스트림을 자동으로 열게됩니다. 표준 스트림을 이용한 파이프라인과 리다이렉션이 가능합니다. 파이프라인은 한 명령의 출력을 다른 명령의 입력으로 사용하는 것이고, 리다이렉션은 명령의 입력이나 출력을 파일로 대체하는 것입니다.

리눅스에서는 표준 입력, 표준 출력, 표준 오류를 파일로 리다이렉션 할 수 있습니다. 리다이렉션을 쓰고 싶다면 기호인 >, < 를 사용합니다. 다음은 몇 가지 예시입니다.

• > : 출력 리다이렉션
  • command > file : command 의 출력을 file 로 저장합니다. file 이 존재하지 않으면 생성합니다. 이미 존재하는 파일이면 덮어씁니다.
  • command1 > file1 2>&1 : command1 의 표준 출력과 표준 오류 출력을 모두 file1 로 리다이렉션합니다. 2>&1 은 표준 오류 출력을 표준 출력으로 리다이렉션 하는 것을 의미합니다.
• >> : 출력 리다이렉션(추가 모드)
  • command >> file : command 의 출력을 file 에 추가합니다. file 이 존재하지 않으면 생성합니다.
• < : 입력 리다이렉션
  • command < file : command 의 입력을 file 로부터 읽어옵니다.
• << : 여러 줄의 입력을 받습니다.
  • command << EOF : EOF 라는 문자열을 입력할 때까지 입력된 모든 내용을 command 의 입력으로 넘깁니다.

예시:

• ls > file.txt : ls 명령의 결과를 file.txt 파일에 저장합니다.

• ps aux > ps.txt : ps aux 명령의 결과를 ps.txt 파일에 저장합니다.

  • 정확하게 말하자면, ps aux 의 출력 스트림을 ps.txt 이라는 파일로 전환하여 저장하는 것을 의미한다. 따라서 ps aux 명령의 결과는 콘솔의 화면이 아닌 ps.txt 파일에 기록된다.

    

    ps aux 명령이 실행되지 않고 ps.txt  파일에 저장되는 모습

• cat < file.txt : file.txt 파일의 내용을 출력합니다.
• sort < file.txt > sorted_file.txt : file.txt 파일의 내용을 알파벳순으로 정렬한 후 sorted_file.txt 파일에 저장합니다.
• head < ps.txt : head 명령은 파일의 처음 부분을 설명한 라인(line) 만큼 출력하는 명령이다. 기본값으로 10줄이 세팅 되어 있다. ps.txt 파일의 처음 10줄을 head 입력 스트림으로 전환하여 보내게 된다.
  • 응용 : head < ps.txt > sample.txt
    1. ps.txt 의 내용을 head 명령의 입력 스트림으로 전환하여 전송한다.
    2. head 명령은 입력 받은 ps.txt 의 내용에서 10줄을 출력한다.
    3. head 명령의 출력 스트림을 sample.txt 파일에 연결한다.
    4. head 명령의 출력 스트림은 결과를 sample.txt 파일에 저장한다.

파이프(Pipe)

파이프(Pipe)는 한 명령어의 출력을 다른 명령어의 입력으로 사용할 수 있게 해주는 기능입니다. 파이프라인(Pipeline)은 파이프를 사용해 여러 명령어를 연결하여 실행하는 것입니다.

파이프는 | 기호를 사용합니다. 다음은 파이프의 예시입니다.

• command1 | command2 : command1 의 출력 스트림을 command2 의 입력 스트림으로 전달합니다.

예시:

• ls | grep file : 디렉토리의 파일 목록을 출력하고, 그 중 "file" 이라는 문자열이 포함된 파일만 검색합니다.

  • [/bin 디렉토리 안] ls -l | grep ssh : 결과 grep 명령어는 추후에 정리

    

ssh 문자열이 들어있는 모든 파일들을 검색

• ps aux | grep firefox : 프로세스 목록을 출력하고, 그 중 "firefox" 라는 문자열이 포함된 프로세스만 검색합니다.

• cat file.txt | grep keyword | wc -l : file.txt 파일의 내용 중 "keyword" 라는 문자열이 포함된 라인의 개수를 출력합니다.

  위의 예시에서 grep 과 wc 는 앞선 명령어의 출력을 입력으로 받아 처리합니다. 이렇게 명령어를 파이프라인으로 연결함으로써, 여러 개의 명령어를 조합해 원하는 결과를 얻을 수 있습니다.

파이프라인 실행 과정

터미널은 하나의 프로세스이고, 명령어 실행은 해당 터미널의 정보를 기준으로 백그라운드에 자식 프로세스가 fork 되어 명령어를 실행하게 된다.

즉 ls 명령어를 입력하면, 자식 프로세스 1개가 fork 되어 백그라운드에서 부모 프로세스의 정보를 기준으로 해당 명령어 즉, stdin(표준 입력 스트림) 을 통해 정보를 입력받고 stdout(표준 출력 스트림) 을 통해 ls 명령어를 호출한 터미널로 정보를 반환한다.

그럼 파이프(Pipe) 끼리 어떻게 연결되나?

$ ls | sort | less

동작과정

1. ls 를 실행하는 자식 프로세스 및 파이프 명령어 개수 만큼 프로세스를 fork 한다. 프로세스는 wait 상태로 대기한다.
2. 부모 프로세스로부터 stdin 을 통해 정보를 받는다.
3. ls 프로세스는 ls 명령을 실행한다.
4. ls 프로세스는 stdout 을 통해 다음 자식 프로세스 stdin 으로 데이터를 출력한다.
5. 반복하고 마지막 프로세스가 부모 프로세스로 stdout 을 return 하고 부모 프로세스는 결과를 출력한다.

부모 프로세스 → … → stdin → 프로세스 내부 명령 실행 → stdout → stdin → … → 부모 프로세스

출력 관련 명령어

파일 일기

man : 메뉴얼 출력 명령어

• man <명령어>
• 명령어에 대한 메뉴얼을 출력하는 명령어

cat : 파일 내용 출력

• cat <옵션> <파일 이름>
• 파일 내용을 출력하는 명령어
  • 다른 CLI 도구나 파일로 리디렉션 하는 데 기본적으로 사용하는 명령이므로 잘 기억할 것
• 자주 쓰는 옵션
  • -n : Line 번호와 함께 출력

-n 옵션으로 파일 내용 앞 line 번호가 쓰여진 것을 확인할 수 있다

more : 파일을 화면 단위로 끊어서 출력

• more <옵션> <파일 이름>
• 자주 쓰는 옵션
  • +<number> : 예) +3 : 입력한 line 을 포함한 페이지를 추력(3번째 줄부터 출력)
  • +/<string> : 예) +/Gatsby : 입력한 문자열이 포함된 페이지를 추력 (Gatsby 문자열을 포함한 줄부터 출력)

less : 파일 내용 출력

• less <옵션> <파일 이름>
• 자주쓰는 옵션
  • -N : line 번호와 함께 출력

head : 파일 앞부분 출력

• head <옵션> <파일 이름>
• 자주 쓰는 옵션
  • -n <number> : 지정한 라인까지 출력

tail : 파일 뒷부분 출력

• tail <옵션> <파일 이름>
• 자주 쓰는 옵션
  • -n <number> : 지정한 라인까지 출력
  • -f : 즉시 종료되지 않고, 파일의 내용이 추가되는 상태를 지켜보면서 계속 이어서 출력
    • -f 옵션은 시스템 관리자라면 필수적으로 알아야 하는 옵션
    • 애플리케이션 로그가 쌓이는 것을 실시간으로 확인하고자 할 때 많이 사용한다.

이 외의 기타 명령어

• wc : 파일의 줄, 단어 및 문자 수를 계산하는 데 사용

  • 옵션
    • -l : 줄 수만 계산
    • -w : 단어 수만 계산
    • -c : 문자 수만 계산

• awk : awk는 텍스트 파일을 처리하는 프로그램으로, 파일이나 텍스트 데이터를 레코드와 필드로 구분하여 처리할 수 있습니다. 레코드는 텍스트 파일에서 행을 의미하며, 필드는 레코드 안에서 구분자로 구분된 데이터를 의미합니다. awk는 이러한 레코드와 필드를 기반으로 다양한 데이터 처리 작업을 수행할 수 있습니다. 대표적으로 데이터 추출, 통계, 변환 등의 작업이 있습니다. awk는 유닉스, 리눅스 등에서 기본적으로 제공되는 명령어 중 하나입니다.

  • 기본 구조 : awk 'condition {action}' <파일 이름>

    awk는 텍스트 파일을 처리하는 프로그램으로, 파일이나 텍스트 데이터를 레코드와 필드로 구분하여 처리하는 기능을 제공합니다. awk는 이러한 레코드와 필드를 기반으로 데이터를 추출하거나 통계, 변환 등의 작업을 수행할 수 있습니다.

    자주 사용되는 기본적인 awk 명령어는 다음과 같습니다.

  • awk '{ print $1 }' file.txt : file.txt 파일에서 첫 번째 필드를 출력합니다.

  • awk '{ print $NF }' file.txt : file.txt 파일에서 마지막 필드를 출력합니다.

  • awk '{ print NF }' file.txt : file.txt 파일에서 필드의 수를 출력합니다.

  • awk '/pattern/ { print }' file.txt : file.txt 파일에서 "pattern"이 포함된 라인을 출력합니다.

  • awk '{ s += $1 } END { print s }' file.txt : file.txt 파일에서 첫 번째 필드의 합을 출력합니다.

    여러 가지 기능을 조합하여 사용할 수도 있습니다. 예를 들어, 다음과 같은 명령어는 file.txt 파일에서 첫 번째 필드가 3인 라인을 출력합니다.

  • awk '$1 == 3 { print }' file.txt

• cut : 파일에서 특정 열을 추출, 기본 구분 기호는 탭 문자이다.

  • 옵션
    • -f :
    • -d : 구분 기호 설정 옵션 (ex) cut -d ‘,’ : 쉼표로 구분 기호를 설정
    • —output-delimiter : 출력 구분 기호 설정 (기본 설정은 입력 구분 기호와 같다)

• join : 파일의 공통

• paste : 여러 텍스트 파일을 수평적으로 join, merge 하는 유닉스 커맨드 라인 유틸리티

  

- 예제 파일

![](https://velog.velcdn.com/images/qnddj-kjh/post/e5933db3-31f5-4211-afa4-927325d40ec9/image.png)


- 옵션
    - `-s` : 수평이 아닌 수직으로 값을 읽어서 수평으로 출력한다.

        ![](https://velog.velcdn.com/images/qnddj-kjh/post/0aba0e30-e995-4377-bd85-31e5aaad969d/image.png)


    - `-d` : 구분자를 지정할 수 있다.

    ![](https://velog.velcdn.com/images/qnddj-kjh/post/e5851bac-e9ba-46ca-8384-974b3ac1f9c0/image.png)

• sed : 문자열 대체 (찾기 및 바꾸기)

  • sed 's/<찾을문자열>/<바꿀문자열>

    

- 보시다시피 화면에 결과를 출력만 하고 파일은 바뀌지 않는다 리디렉션을 해주거나 `-i` 옵션을 주어 원본 파일을 변경해야 한다.
- 옵션
    - `-d` : 삭제
    - `-a` `-i` : 줄 추가 또는 삽입

• sort : 파일 내에서 줄이나 열을 정렬하는데 사용한다. 기본적으로 줄 시작 부분의 문자를 기준으로 다음 순서를 정렬한다.

  • 오름차순 숫자, 오름차순 문자(소문자 먼저, 그 다음 대문자)

  • 옵션

    • -r : 정렬 기준 역순으로 바꾼다

    • -n : 기본 정렬은 숫자 값이 아닌 문자로 숫자를 정렬한다. 숫자 값으로 정렬하려면 -n 옵션 사용

    • -k : 줄의 시작이 아닌 특정 열을 기준으로 파일을 정렬할 때 사용

      

    • -u : 정렬한 다음 중복을 제거한다

    • -f : 대소문자 구분 안함

• uniq : 중복된 항목을 제거하는 커맨드 라인 유틸리티, 보통 sort 명령어로 정렬을 한 결과를 파이프로 uniq 에 전달하여 중복 내용을 제거한다

  • 예제 파일

    

- 사용법
    - `sort input.txt | uniq`

        ![](https://velog.velcdn.com/images/qnddj-kjh/post/7525ece0-4d07-4fc8-bc70-2e665a2786c0/image.png)



- 옵션
    - `-u` : 중복되지 않은 라인만 표시한다. 위 예제에서 line 과 bat 은 포함되지 않는다.
    - `-d` : 중복되는 라인만 표시한다. 위 예제에서 line 과 bat 이 해당된다.
    - `-c` : 중복 횟수를 세어 준다.
    - `-i` `--ignore-case` : 대소문자 구분 무시 옵션

파일 및 디렉토리 찾기 관련

find : 파일 검색

파일 검색 기본 명령어 중 하나. 파일 권한, 소유권, 수정 날짜, 크기 등과 같은 특정 기준에 따라 파일을 검색 할 수 있다.

• 주의점 : 위치 선정을 하지 않을 경우 기본적으로 현재 디텍토리만 검색하기 때문에 원하는 결과를 얻지 못 할 수 있다. 찾고자 하는 위치를 지정해서 사용하는 것이 좋다.

$ find <위치> <옵션> 검색할 내용

• 옵션
  • -name 내용 : 지정한 내용의 이름을 가진 파일을 찾음
  • -type <옵션> : 옵션에 따른 형태를 가진 파일을 찾음

$ find . -name '이름' # 찾을 파일 이름을 지정해서 찾기 . 는 현재 디렉토리를 뜻함
$ find . -name '이름' -type d # -type d 는 디렉토리만 찾기
$ sudo find / -size+10M # 10M 이상 찾기 디렉토리 권한 때문에 sudo 사용
# / 는 루트 디렉토리를 뜻함
$ find . -empty # 빈 파일 찾기
$ find . -newer practice.txt # practice 파일 보다 최근에 변경된 파일 찾기

locate : 특정 파일 위치 찾기

특정 파일의 위치를 모를 때 활용 find 명령어에 비해 빠르지만 데이터베이스를 이용하기 때문에 정기적인 업데이트를 필요로 한다. updatedb 에 의해서 생성된 미리 빌드된 파일들의 데이터베이스를 통해 검색이 되기 때문. 속도 향상을 위해 만들어진 유틸리티 이므로 전체적인 효율성과 정확성은 조금 떨어진다.

• **locate(mlocate) 프로그램 설치하기**

  리눅스 배포판에 따라 locate 명령어가 기본으로 제공되는 경우도 있지만 없는 경우 설치가 필요. 기존에는 locate 패키지를 사용 최근에는 mlocate 패키지를 추천한다 (관리자 권한 필요)

    $ sudo apt-get install mlocate

• locate 명령어가 빠른 이유는 검색 DB 를 미리 생성하기 때문 (파일 목록 데이터베이스, mlocate.db 파일) 따라서 locate 명령어를 처음 사용하는 경우 DB 파일을 먼저 생성해야한다.

• ****DB 파일 갱신하기(관리자 권한 필요)****

    $ sudo updatedb

• 사용예

    $ locate gatsby.txt  # 파일 이름으로 검색
    $ locate -n 10 *.txt # 검색할 파일 수 지정하여 찾기 모든 txt 파일 중 10개

which : 실행파일 위치 식별

which 명령어는 실행 가능한 파일의 경로를 찾아주는 프로그램입니다.

검색하려는 모든 파일이 실행 파일인 경우 which 명령어가 유용. $PATH 시스템 환경변수에서 이진 파일을 매우 효과적으로 검색

$ which ls
usr/bin/ls

$ which python3
/usr/bin/python3

패턴으로 찾기 관련

grep 명령어를 사용하여 파일 내에서 특정 패턴을 검색할 수 있습니다.

$ grep <패턴> <파일명>

사용 예

$ grep 'hello' file.txt
$ grep -i 'hello' file.txt
$ grep -n 'hello' file.txt
$ grep -r 'hello' ./directory

• 옵션

| 옵션 | 설명 |
| --- | --- |
| -i | 대소문자를 구분하지 않고 검색 |
| -v | 지정한 패턴을 포함하지 않는 라인을 출력 |
| -n | 라인 번호를 함께 출력 |
| -w | 지정한 패턴이 단어로 구분되어 있는 경우에만 검색 |
| -r | 하위 디렉토리를 포함하여 모든 파일에서 검색 |
| -l | 파일명만 출력 |
| -c | 일치하는 라인 수를 출력 |
| -H | 파일명을 출력 |
| -E | 확장 정규식 사용 |
| -F | 정규식이 아닌 문자열 검색 |
| -m | 최대 검색 결과 갯수 제한 |

• 예시 (끝에는 전부 파일명)
  • 단어 단위로 검색 : grep -w
  • 검색된 문자열이 포함된 라인 번호 출력 : grep -n
  • 하위 디렉토리를 포함한 모든 파일에서 문자열 검색 : grep -r
  • 최대 검색 결과 갯수 제한 : grep -m 10
  • 문자열 A로 시작해서 문자열 B로 끝나는 패턴 찾기 : grep '^A$B'

정규표현식

정규표현식(regular expression)은 문자열을 처리하는 방법 중의 하나로 특정한 조건의 문자를 '검색'하거나 '치환'하는 과정을 매우 간편하게 처리할 수 있도록 하는 수단이다. 정규표현식은 일종의 패턴(pattern)이며, 이 패턴을 통해 문자열을 처리한다.

정규표현식 문법

• . : 임의의 한 문자
• ^ : 문장의 시작
• $ : 문장의 끝
• [] : 문자의 집합 중 하나
• [-] : 문자의 집합 중 범위
• () : 그룹화
• | : or 연산자
• ? : 0 또는 1회 발생
• `` : 0회 이상 발생
• + : 1회 이상 발생
• {n} : n회 발생
• {n,} : n회 이상 발생
• {n,m} : n회 이상, m회 이하 발생

정규표현식 예제

• .

  모든 문자 하나를 의미합니다.

• ^

  문자열 또는 행의 시작을 의미합니다.

• $

  문자열 또는 행의 끝을 의미합니다.

• []

  대괄호 안에 있는 문자 중 하나와 일치합니다.

• [^]

  대괄호 안에 있는 문자를 제외한 문자 중 하나와 일치합니다.

• [-]

  대괄호 안에 있는 문자의 범위와 일치합니다.

• ()

  괄호 안의 문자열을 그룹으로 묶습니다.

• |

  둘 중 하나와 일치합니다.

• ?

  0회 또는 1회를 의미합니다.

• ``

  0회 이상을 의미합니다.

• +

  1회 이상을 의미합니다.

• {n}

  n회를 의미합니다.

• {n,}

  n회 이상을 의미합니다.

• {n,m}

  n회 이상, m회 이하를 의미합니다.

정규표현식을 사용하는 명령어

• grep: 파일 내에서 특정 패턴을 검색할 때 사용합니다.
• sed: 파일 내에서 문자열을 대체(찾기 및 바꾸기)할 때 사용합니다.
• awk: 파일 내에서 특정 패턴을 검색하고 조작할 때 사용합니다.
• find: 파일 검색 기본 명령어 중 하나입니다.
• locate: 특정 파일의 위치를 찾을 때 사용합니다.
• which: 실행 파일의 위치를 식별할 때 사용합니다.

출처

https://recipes4dev.tistory.com/171 https://www.lesstif.com/lpt/linux-uniq-95879394.html https://blog.ronin.cloud/10-simple-linux-commands/ http://hyeonjae-blog.logdown.com/posts/654302 https://www.computerhope.com/unix/uuniq.htm https://hitomis.tistory.com/84

IDE - Visual Studio Code

간단히 홈페이지에서 설치 하면 끝!

Node.js 설치

• 특징
  • 빠르다
  • 언어수준(Javascript)에서 비동기 완성
  • 확장성

Node.js 또한 홈페이지에서 설치하면 끝이다. version 은 LTS version 을 추천한다. LTS(Long Term Support) 장기간동안 지원하는 version 이다. 그렇지만 Node.js 의 최신의 기능을 사용하고 싶다면 Current Version 을 다운 받으면 된다. Node 의 version 을 관리 할 수 있는 version manager 가 존재하는데 대표적으로 nvm, n 이 있다. 필자는 n 을 사용하고 싶지만 windows 사용자라서 사용하지 못한다. ㅠ 그렇다고 nvm 사용하기에는 귀찮으므로 pass

Formatting - Prettier

1. vsc Extends 에서 Prettier 검색 후 install
2. npm install --save-dev prettier 명령으로 prettier dependency 설치
3. 프로젝트 디렉토리에 .prettierrc 설정파일 생성 위와 같이 Option 들을 끄고 킬 수 있다.
   • semi : 세미콜론 유무
   • singleQuote : 홑따옴표 사용 유무 필자는 Java 를 많이 사용하고 있기에 위처럼 옵션을 주었다 더 다양한 옵션들이 존재하니 prettier 홈페이지에서 문서를 보면 된다.

     https://prettier.io/docs/en/options.html

4. 해당 프로젝트에서 prettier 적용 프로젝트 디렉토리에서 .vscode 패키지 생성 후 settings.json 파일을 만들어 준다. 해당 프로젝트에서 사용할 설정을 정해주는 것 javascript 를 저장할 때 포멧하고 기본 포멧터로 prettier 를 사용하겠다고 설정한 것이다.

Linting - ESLint

1. vsc Extends 에서 ESLint 확장팩 install
2. ESLint dependency 추가 npm install --save-dev eslint
3. ESLint 설정 파일 생성 .eslintrc.js 명령어로도 가능하다. npx eslint --init 간단하게 설정하기 위해서 필자는 이미 설정된 airbnb 확장을 사용할 것이다.
4. airbnb 설정 적용 필요한 dependency 들을 설치합니다. npm install --save-dev eslint-config-airbnb-base eslint-plugin-import
5. .eslintrc.js 에서 설정 적용

   module.exports = {
   extends: ["airbnb-base"],
   };

   airbnb 설정이 적용이 되지만 여기서 prettier 와 eslint 가 충돌하는데 문제 해결을 위한 설정이 이미 만들어져 있다. npm install --save-dev eslint-config-prettier

   module.exports = {
   extends: ["airbnb-base", "prettier"],
   };

   eslint 가 prettier 에서 고친 것에서 에러를 잡지 않게 설정되었다. 또 한가지 eslint-prettier plugin 이 잘 동작하기 위해서는 항상 맨 마지막에 넣어주는 것이 좋다.

추가로 node 관련된 plugin 도 넣어보자. npm install --save-dev eslint-plugin-node

module.exports = {
  extends: ["airbnb-base", "plugin:node/recommended" , "prettier"],
};

이제 eslint 에서 node 관련된 에러도 잡아줄 것이다.

Type Checking - TypeScript

javascript 는 동적으로 타입이 변하는 언어이다. type checking 관련 문제가 안 생기게 하기 위해 Typescript 를 사용

1. typescript dependency 추가 npm install --save-dev typescript

2. js 파일 최상단 // @ts-check 추가

이것만 해줘도 간단하게 type checking 이 가능하다.

node 관련 type npm install --save-dev @types/node node 에서 자주 사용하는 객체들의 type 들이 정의되어 있다. vscode 가 위의 정보를 바탕으로 type check 를 도와준다.

Javascript 로 프로젝트를 할 것이기 때문에 Typescript 의 type checking 만 도움 받을 것이다.

3. jsconfig.json 설정파일 생성 strict : 강하게 규칙을 잡는것 include : src 밑의 모든 폴더와 파일들 대상

풀이

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class Main {
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

        String input = "0";
        while (!(input = br.readLine()).equals("0")) {
            int len = input.length();
            boolean flag = true;
            if (len != 1)
                for (int i = 0; i < len / 2; i++) {
                    if (input.charAt(i) != input.charAt(len - 1 - i)) {
                        flag = false;
                    }
                }

            if (flag) {
                System.out.println("yes");
            } else {
                System.out.println("no");
            }
        }
    }
}

반성

구현을 하는 문제이고 문자열을 얼마나 잘 다루는지 보는 문제인데...간단하게 생각안하고 또 어렵게 생각했다. 처음 풀었던 방법은 앞 뒤 자르고 StringBuffer 써서 뒤를 다시 역순 정렬...그리고 비교하여 같으면 yes 아니면 no 출력으로 풀었는데 이 경우 33333 같은 홀수 일때 split 을 사용하면 잡을 수가 없기에 charAt 으로 순차적으로 앞뒤 비교하여 틀린순간 잡는 방법으로 바꾸었다...나는 멍청해...

public static main(String[] args) throw IOException {

    BufferedReader br = new BufferedReader(new InputStreamReader(System.in);

    int l = Integer.parseInt(br.readLine());
    String s = br.readLine();

        long result = 0;
        long temp = 1;
        for (int i = 0; i < l; i++) {
            result += ((s.charAt(i) - 'a' + 1) * temp);
            temp = (temp * 31) % 1234567891;
        }

        System.out.println(result % 1234567891);
}

주의

제곱이 들어가는 점이 가장 큰 주의점이다 여기서 r로 지정된 31의 50제곱은 long 타입의 범위를 넘어간다.

중간 연산에서 계속해서 M 을 나누어 주는 연산을 돌려야 범위 안에서 계산이 된다.

HyperText 즉 HTML 이런 문서 간의 링크를 통해서 연결할 수 있는 것으로 전송하는 프로토콜로 시작되었고, 지금은 HTTP 메시지에 모든 것을 넣어서 전송한다.

HTTP 기초

HTTP

Hyper Text Transfer Protocol 의 약자로 HTML(하이퍼텍스트) 문서를 교환하기 위해 만들어진 프로토콜(통신 규약) 이다. 지금은 HTTP 메시지에 모든 것을 넣어서 전송한다.

• HTML, TEXT

• 이미지, 음성, 영상, 파일

• JSON, XML (API) 등

  거의 모든 형태의 데이터 전송 가능하고 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용하는 HTTP 시대이다.

• 웹상에서 네트워크로 서버끼리 통신을 할 때 어떠한 형식으로 서로 통신을 하자고 규정해 놓은 통신 형식 혹은 통신 구조 이다

• HTTP 는 TCP/IP 기반으로 되어있다.

• 요청과 응답 구조로 되어있다.

  • 클라이언트가 HTTP request 를 서버에 보내면 HTTP response 를 보낸다.
  • 모든 통신이 요청과 응답으로 이루어진다.

• HTTP 는 Stateless 이다

  • state (상태) 를 저장하지 않는다
  • 요청이 오면 그에 응답을 할 뿐, 요청/응답 이 서로 연결되어 있지 않다
  • 각각의 요청과 응답은 독립적인 요청과 응답이다.
  • 한계
    • 모든것을 무상태로 설계 할 순 없다 (대표적 예시: 로그인)
    • 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지
    • 상태 유지는 최소한만 사용

      역사

• HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더 X

• HTTP/1.0 1996년: 메서드, 헤더 추가

• HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전

  • RFC2068(1997) -> RFC2616(1999) -> RFC7230~7235(2014)

• HTTP/2 2015년: 성능 개선

• HTTP/3 진행중: TCP 대신에 UDP 사용, 성능 개선

기반 프로토콜

• TCP: HTTP/1.1, HTTP/2
• UDP: HTTP/3 진행중

HTTP 특징

• 클라이언트 서버 구조
• 무상태 프로토콜(스테이스리스), 비연결성
• HTTP 메시지
• 단순함, 확장 가능
  • 무상태 프로토콜의 특징으로 응답 서버를 쉽게 바꿀 수 있다.
  • 반대로 상태유지 (Stateful) 은 항상 같은 서버가 유지되어야 하여서 서버를 쉽게 바꿀 수 없다. (상태가 사라지니깐, 처음부터 다시 요청해야 한다.)

HTTP Message

서버와 클라이언트 간에 데이터가 교환되는 방식이며 ASCII 로 인코딩된 텍스트 정보이며 여러 줄로 되어있다. 메시지 타입은 두 가지가 있다.

• 요청 (Request)
• 응답 (Response)

HTTP message 구조 출처 : 코드스테이츠

HTTP Request

구조

• start-line (시작 줄)

  • HTTP 메서드
    • 서버가 수행해야 하는 동작을 나타낸다.
  • 요청 타겟
    • 주로 URL 또는 프로토콜, 포트, 도메인의 절대 경로로 나타낸다. 이들은 요청 컨텍스트에 의해 특정지어지고 요청 타겟 포맷은 HTTP 메소드에 따라 달라진다.
    • 형식 존재
      • origin : GET, POST, HEAD, OPTIONS
        • ex) POST / HTTP 1.1, HEAD /test.html?query=alibaba HTTP/1.1 등
      • absolute : 대부분 GET
        • ex) GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
      • authority : HTTP 터널을 구축하는 경우에만 CONNECT 와 함께 사용
        • ex) CONNECT developer.mozilla.org:80 HTTP/1.1
      • asterisk : OPTIONS 와 함께 별포 (’*’) 하나로 간단하게 서버 전체를 나타낸다.
        • ex) OPTIONS * HTTP/1.1
  • HTTP 버전
    • 응답 메시지에서 써야 할 HTTP 버전을 알려준다.

• 헤더 (Header)

  • 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 해준다

  • HTTP 헤더의 기본 구조를 따른다.

    다양한 요청 헤더가 있는데 다음과 같은 몇몇 그룹으로 나눌 수 있다.

  • General : 요청과 응답 모두에 적용되지만 바디에서 최종적으로 전송되는 데이터와는 관련이 없는 헤더.

  • Request : 페치될 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더.

  • Response : 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더.

  • Entity : 컨텐츠 길이나 MIME 타입과 같이 엔티티 바디에 대한 자세한 정보를 포함하는 헤더.

• 본문 (Body)

HTTP Response

• start-line (시작 줄)

  • HTTP 메서드
    • 서버가 수행해야 하는 동작을 나타낸다.
  • 상태 코드 (HTTP Status Code)
  • HTTP 버전
    • 응답 메시지에서 써야 할 HTTP 버전을 알려준다.

• 헤더 (Header)

  • 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 해준다

  • HTTP 헤더의 기본 구조를 따른다.

    다양한 요청 헤더가 있는데 다음과 같은 몇몇 그룹으로 나눌 수 있다.

  • General : 요청과 응답 모두에 적용되지만 바디에서 최종적으로 전송되는 데이터와는 관련이 없는 헤더.

  • Request : 페치될 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더.

  • Response : 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더.

  • Entity : 컨텐츠 길이나 MIME 타입과 같이 엔티티 바디에 대한 자세한 정보를 포함하는 헤더.

• 본문 (Body)

  • 본문은 요청의 마지막 부분에 들어갑니다. 모든 요청에 본문이 들어가지는 않습니다. GET, HEAD, DELETE , OPTIONS처럼 리소스를 가져오는 요청은 보통 본문이 필요가 없습니다. 일부 요청은 업데이트를 하기 위해 서버에 데이터를 전송합니다. 보통 (HTML 폼 데이터를 포함하는) POST 요청일 경우에 그렇습니다.
  • 넓게 보면 본문은 두가지 종류로 나뉩니다.
    • 단일-리소스 본문(single-resource bodies): 헤더 두 개([Content-Type](https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Content-Type)와 [Content-Length](https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Content-Length))로 정의된 단일 파일로 구성됩니다.
    • 다중-리소스 본문(multiple-resource bodies): 멀티파트 본문으로 구성되는 다중 리소스 본문에서는 파트마다 다른 정보를 지니게 됩니다. 보통 HTML 폼 (en-US)과 관련이 있습니다.