교보 DTS CDA 3기 7주차 후기

OK__UK·2025년 4월 25일

교보DTS CDA

목록 보기
5/16
post-thumbnail

시작하기 전,,,

글로벌 소프트웨어캠퍼스와 교보 DTS가 함께 진행하는 챌린지입니다

👉신나는 강의 바로 드가자~

4/21 31일차

오늘은 월요일~ 왜 이제 월요일?
어제 시험 보니까 월요일~ 시험이 없는 세계선에 살고싶다~

오전

오늘은 보안에 대한 강의를 한다고 하셨음

1. SSH

  • 네트워크로 원격지에 접속하기 위한 것

  • 이전엔 telnet, ftp가 존재 -> 원격지를 접근할때 인증이 암호화가 안되는것이 문제

  • 원격 시스템에 안전하고 암호화 등을 수행할 수 있도록 하는 프로토콜

  • 클라이언트-서버 모델 기반 작동

  • SSH 서비스

    1. 안전하게 원격 접속: 암호화된 연결을 통해 원격 시스템에 안전하게 접속, 전송할때 암호화 적용으로 인해 도청, 중간자 공격 방지
    2. 인증 및 권한 부여: 비밀번호 인증 또는 키 기반 인증 제공, 키는 공개 키와 개인 키를 쌍으로 사용
    3. 데이터 전송 보호: 전송시 데이터를 암호화하여 전송하여 도난, 변조를 방지, SCP를 이용하여 전송
  • 사용법

  • SSH

  • SCP

  • SSH 연결안하고 파일 확인

  • 받아오기도 가능

  • 서버에서 공개 키 파일

  • 서버 공개키 클라이언트에서 저장 파일

  • 연결과정

    1. 초기 연결: 클라이언트가 서버에 22포트로 요청, 서버는 클라이언트에게 응답을 보냄
    2. 서버 인증: 서버는 공개키를 클라이언트에게 전송, 클라이언트는 공개키를 로컬에 저장된 키와 비교하며 검증
    3. 세션 키 생성: 클라이언트와 서버간의 키 교으로 대칭키생성(세션 키), 세션키를 서버의 공개키로 암호화한후 전송
    4. 클라이언트 인증
      • 비밀번호 인증: 클라이언트가 사용자 이름, 비밀번호로 인증
      • 공개키 인증: 개인키로 서명한 메세지를 서버에 전송, 그전에 클라이언트의 공개키를 서버의 공개키로 암호화해서 전송, 서버는 받은 개인키를 검증
    5. 데이터 연결: 인증 완료되면 서버 생성된 세션 키를 사용하여 대칭키로 암호화로 통신 시작
  • 주요 파일

  • 사실 난 안되서 한시간 못들음 해결하느라,,ㅠㅠ

오후

2. SSH 키 인증 알고리즘

  • 공개키: 누구나 볼 수 있는 공개된 키, 서버에 저장
  • 개인키: 클라이언트,서버의 개인소유로 비밀로 유지, 공개키와 한쌍, 공개키로 암호화한걸 복호화할때 사용
  • 인증 방법
    1. SSH 키 생성: 클라이언트에서 공개키, 개인키 생성(ssh-keygen)
    2. 공개키 배포: 클라이언트에서 서버에게 공개키 배포, 서버의 ~/.ssh/authorized_keys에 저장
    3. 클라이언트가 서버에 접속 요청
    4. 서버가 클라이언트에 인증
      • 서버가 난수 메시지 생성: 클라이언트의 공개키로 암호화해서 클라이언트에게 전송
      • 클라이언트가 복호화: 전송된 메세지를 개인키로 복호화한다음 다시 서버로 전송
      • 서버가 응답: 복호화한 메세지 일치하는지 인증하고 신뢰
    5. 세션 암호화 설정 끝~
  • 파라미터 변경하면 sshd 데몬을 재시작해야함
  • SSO: 사용자가 한번 인증하면 다음부터 인증안해도 된다
  • SSH+SSO 하기
    1. SSH Agent 활성화: SSH Agent를 메모리에 실행, 환경 변수 SSG_AGENT_SOCK 설정
    2. 키 추가: 개인키를 SSH Agent에 추가 인증
    3. 서버 설정: 서버의 /etc/ssh/sshd_config파일에 인증 활성화
    4. 접속

3. 방화벽

  • iptables, firewall 있음
  • iptables는 6버전, firewall은 7버전 그렇듯이 버전이 낮으면 더 쓰기 어렵다 그래서 firewall을 더많이 쓴다, 그리고 우선순위가 firewall
  • 같이 쓰면 충돌나서 하난 종료해야함

4. iptables

  • 리눅스에서 네트워크 트래픽을 관리하고 보안을 강화하기 위해 사용되는 도구 -> 정확하게 방화벽자체를 말하기보단 넷필터이며 input,output을 제어하는것

  • 커널에 내장되어 있으며 데몬은 아님

  • firewall 정지

  • 구성 요소

    1. 테이블: 패킷 처리 유형에 따른 규칙 집합
      • filter: 기본 테이블, 패킷 필터링 담담
      • nat: 네트워크 주소(NAT)을 처리
      • mangle: 잘안씀
    2. 체인: 테이블 내부에서 규칙 적용
      • INPUT: 시스템으로 들어오는 패킷 규칙 적용
      • OUTPUT: 시스템에서 나가는 패킷 처리
      • FORWARD: 통과되는 패킷처리(라우터같이 날 걸쳐가는 느낌이 통과)
    3. 타겟: 규칙이 적용된 후 수행할 작업
      - ACCEPT: 패킷을 허용, 규칙에 맞는것을 허용
      - DROP: 패킷을 차단, 응답안함
      - REJECT: 패킷을 차단, 오류 메세지 보냄
  • 옵션

  • 작동원리: 네트워크 인터페이스를 통과하는 패킷을 검사, 체인의 규칙에 따라 순차적으로 처리후 타켓 작업 수행, 규칙에 매칭안되면 다음 규칙 순차적으로 진행

  • 앞에서 걸리면 뒤에 규칙이 허용이여도 안됨

  • 규칙 삭제

  • 규칙 초기화

  • 규칙 순서 변경

  • 패킷 흐름

    1. 패킷이 들어오면 먼저 INPUT 체인에서 확인
    2. 시스템을 통과해야 하는 경우 FORWARD 체인으로 전달
    3. 나가는 트래픽은 OUTPUT 체인에서 처리
  • DROP REJECT 차이점

    • 메세지를 반환 하는가 아닌가
    • DROP는 상대에게 서버가 존재하는지 조차도 알려주고싶지않은것
    • REJECT는 디버깅등 문제 해결을 위해
    • DROP 메세지 리턴 확인

  • 영구적 사용
  • iptables-save으로 규칙을 파일로 저장 하지만 iptables는 데몬이 아니라서 데몬으로 실행할수 있는 패키지를 설치해야함

5. Firewalld

  • 저번에 어떻게 하는지 대충 알아서 알긴함
  • 이번엔 iptables 정지
  • 기본 방화벽 관리 도구
  • 주요 기능
    1. 동적 방화벽 관리: 실시간으로 추가,수정,삭제 가능, 재시작 불필요 리로드하면됨
    2. 영역 기반 관리: zone에 할당하여 관리, 각 영역마다 신뢰 수준이 다르며 규칙집을 포함하고 있음
    3. 서비스 및 포트 관리: 서비스 이름으로 포트를 관리할 수 있음
    4. reich Rules: 복잡한 조건과 작업을 정의할 수 있는 고급 규칙 언어를 제공, 특정시간에만 적용가는한 규칙 등
  • 활성화 및 확인
  • 이러고 존할려고 네트워크 연결햇는데 프티가 안열려서
    난 못들음 젠장,,, 왜 나만,, 나만,, 나도 하게해줘,, 그러고 강사님에게 해결받았지만 다시 키니 또안되서 포기함,,ㅠㅠ
  • zone 종류
  • dmz-zone 확인

이후

아니 오늘 왜 다안됨? 미침? 도라아러열어럼ㄴ이ㅏ;럼;ㅣ나얼
점심은 kfc먹었는데 할인을 많이 해주네!
암튼 왜 나만 못해!!!!!!!!!!!!!!!!!!!!!!!!!!

4/22 32일차

오늘은 비가 왜이리 많이 오는거야~
덥다가 비오다가 덥다가~ 저번에 산불났을때 많이좀 오지 금방 멈추게!

오전

어제 복습하고 시작!
그리고 어제 안된거 어케 하다보니 해결했는데,, 난 모르겠따~~

1. PAM

  • 과거에는 인증하기위해서는 사용자 접근을 하기 어려운 파일에 직접적으로 접근 해야했다. 즉 자신것 외의 정보까지 확인이 가능하기 때문에 보안적인 문제가 잇음
  • 현재 직접 접근 ㄴㄴ PAM을 통해 인증하여 전달, 그래서 pam에게 인증 요청하고 결과를 반환 받는다
  • 인증은 순서대로 실행 되기때문에 중요한걸 위로 하는게 좋다
  • 인증과정을 응용프로그램이 하지않아 개발과정이 간소화 된다고~ 인증 동작을 제어하니까 안전하게 운영할 수 있다고~
  • 원리
    1. 인증에서 필요한 응용프로그램이 pam에 요청
    2. pam에서 인증요청한 사용자의 정보를 가지고 결과 도출하고 응용프로그램에 전달
  • 구조
    1. 모듈타입
      • auth: 사용자에게 비밀번호를 요청하고 입력 받은 정보가 맞는지 검사하는 모듈
      • account: 사용자가 맞는지를 확인 하는것, 현재 조건에 유효한 인증이 맞는지 검사하는것 즉 페스워드가 맞는지 틀리는지가 아닌 계정 비밀번호 기간 만료 등을 체크
      • password: password를 변경, 갱신하도록 권장하는 모듈
      • session: 사용자가 인증을 받기 전후에 수행해야 할 일을 정의하는 모듈, 이미 연결되어있는지 확인, 로그인하고 아무입력없으면 10분뒤에 로그아웃한다 등
    2. 제어 플래그
      • required: 인증 결과와 관계없이 다음 인증 실행
        • 첫 인증이 실패하면 실패이지만 그뒤의 인증까지 계속 실행하는것, 결국은 실패로 반환한다! 그러나 성공도 마찬가지로 처음이 성공이면 마지막에 성공을 반환
        • 이유는 어디서 틀렸는지라던가 어디서 맞았는지 알려주면 인증 방법을 들킬 수 있는 등 보안적인 문제가 생길 수 있기 때문에
      • sufficient: 인증 결과가 성공일 경우 바로 종료, 위처럼 required처럼 성공했다고 계속 인증을 하는것이 아닌 바로 성공을 반환
      • requisite: 위와 반대로 실패할경우 바로 종료, 똑같이 실패했다고 인증을 계속하는것이 아님
    3. 모듈 이름
      • 여러개가 있는데 대체적으로 변경하지 않는다.
      • 우리는 pam_google_authenticator.so로 실습진행함 점심먹고 하기로해서 뒤에부터함
    4. 모듈 인수
      • deboug: 로로그 파일에 디버그 정보 남기도록
      • no_warm: 경고 메세지를 보내지 않도록
      • use_first_pass, try_first_pass 가 있다

오후

2. PAM 실습

  1. 먼저 pam_google_authenticator.so을 하려면 패키지를 먼저설치해야하는데 우리 레파지토리에서는 제공을안해서 레파지도리부터 설치
  2. 그리고 google authen설치
  3. 이제 우리 스마트폰에 설치
  4. 동기화
  5. 하면 연결된다
  6. ssh구성 수정
    1. 주석
    2. yes
    3. 첫문장 추가
    4. 재시작 sshd 데몬을
  7. 끝~~ 새로운 세션에서 접근 해보자

3. 임의적 접근 제어 DAC

  • 과거에 사용한 방법
  • 리눅스 같은 운여체제에서 가장 기본적으로 사용되는 접근 통제 방식중 하나
  • 사용자가 객체에 대한 권한을 직접 관리, 권한 부여하는것
  • 로그인만하면 자유로운 느낌을 가진다고
  • 소유자 중심의 제어: 시스템 자원의 소유자가 직접 권한 설정 및 변경 가능, chmod로 권한 변경하는 것처럼
  • 신분 기반: 사용자(uid)나 그룹(gid)의 신분 누가 접근하려고 하는지 신분에 따라 허용 여부 결정
  • 유연성: 권한 변경이 자유롭고 구현이 쉬워서 좋음
  • 차이점

4. 강제 접근 제어 MAC

  • 보안 정책과 보안 등급에 다라 시스템 자원에 대한 접근을 제한하는 방식
  • 회사에서 사원증 있다고 아무대나 다들어가는것 아니잖아 들어갈수 있는 장소만 들어갈수 있듯이
  • 주요 개념
    1. 주체: 접근을 시도하는 사용자, 프로세스
    2. 객체: 접근 대상이 되는 파일, 디렉토리, 포트 등
    3. 보안 레이블: 주체와 객체 각각 할당되는 보안 레이블
    4. 정책 기반 통제: 접근 여부는 주체와 객체의 보안 등급을 비교, 정책에 따라 자동으로 결정
    5. 중앙 집중식 관리: 시스템 관리자가 모든 정책과 등급 설정, 사용자는 임의로 조정 못함
    6. 정책에 의한 접근 제한: 주체의 보안 등급이 객체의 등급보다 낮으면 접근 거부 당연한거? 반대로도 같음
    7. 업격한 보안: 루트 계정조차도 정책에 어긋나면 접근 못할 수도
  • SELinux가 그중 하나이다.

5. SELinux

  • 응용프로그램은 아니고 커털에서 작용되는 것으로 시스템에서 독립적으로 작동한다.
  • 위처럼 할때마다 들어가서 확인하고 나오는 느낌?
  • 비활성화를 제외하면 동적으로 변경이 가능하다.
  • 보안 컨텍스트: 리소스에 부여된 보안 레이블, 접근 제어 정책의 핵심 기능
    1. SELinux 사용자: 그그 db만들때 user따로 만들듯이 그런 느낌의 사용자
    2. 역할: 프로세가 어떤역할을 수행할지 구분하는것
    3. 유형,타입(젤 중요): 객체에 대한 접근 권한 결정
    4. 레벨: 잘안씀 접근 등급같은 것
  • 프로세스 도메인: 프로세스에서 접근할수 있는 타입과 매칭이 되어야만 접근이 가능하다.
    • 즉 도메인과 타입이 서로 매칭이 되어야만 접근이 되고 안되면 접근이 안된다 root일지라도
    • 허용범위
    • 매칭 확인
    • 매칭되는 것 알려줌
  • 실습
    • 타입 변경
    • 하지만 임시변경이라는거
    • 영구 변경
    • selinux boolean 값 조회
    • 값 변경
    • 서비스로 포트 추가하기

이후

오늘하루종일 비가 오냐!
비소리가 너무 크게들려!
그리고 다끝나고 우분투 설치하고 ㅋㅋㅋㅋ 왜 안나옴? 이러는데 엔터눌르면 되는거였던것~
암튼 오늘은 점심 짬뽕 먹음

4/23 33일차

오늘부터 도커, 컨테이너를 배운다고했따

오전

1. 가상화

  • 우리 첫주에 했던 가상화에 대해서 다시 설명 해주셨음
  • 클라우드는 가상화를 이용하니까
  • 가상화: 물리적인 리소스를 논리적인 리소스로 만드는 것
  • 전가상화: 자신이 가상화인지 모르게 하는것, 호스트 os위에 하이퍼바이저 위에 게스트 os를 설치해서 사용
  • 반가상화: 자신이 가상화인지 아는 것, 호스트 os가없고 바로 하이퍼바이저 위에 게스트 os를 설치해서 메인 디스크에 연결하는 것

2. 모노리틱 아키텍처, 마이크로 서비스 아키텍처

  • 나는 배포를 기준으로 이해 하긴 했음
  • 모노리틱 아키텍처
    • 여러 기능을 모두 통합한 형태
    • 빌드 배포가 단순
    • 하나의 기능을 업데이트해도 모두를 다시 빌드 배포 해야한다. 그래서 업데이트 주기가 길다
    • 부하가 많이 걸려 서비스를 추가할때도 불필요한 서비스까지 추가해야 함
  • 마이크로 서비스 아키텍처 MSA
    • 독립적으로 배포 가능하게 각각의 기능을 따로 빌드 배포하는 형태
    • 하나의 기능을 업데이트하면 업데이트한 서비스만 빌드하고 배포하면 되서 빠르게 대응가능
    • RestAPI로 통신
    • 초기 설계와 인프라 구축, 운영 등 복잡

3. 배포

  • 인프라자원, 소프트웨어,애플리케이션, 서비스 등을 실제 운영 환경에 설치 및 구성하여 사용하게 해주는 과정
  • 순서
    1. 서버구성
    2. 서버에 응용프로그램 배치
    3. 보안정책 및 테스트 환경등 문제 해결
    4. 실제 환경에 적용
  • 모든 과정이 생각보다 오래걸림
  • 그래서 이걸 해결하기 위해서 컨테이너라는 기능이 생긴것
  • 배포하는 사람 따로 개발자 따로 이렇게 구성되어 있는데 요즘은 개발자도 배포하는 운영환경을 이해하고 컨테이너를 만들어줘야한다! -> DevOps

오후

  • ip 고정치로 만들기

3. 컨테이너

  • 컨테이너는 os상에 논리적인 구획을 만들고, 애플리케이션을 작동히시키 위해 필요한 라이브러리나, 애플리케이션등을 하나로 모아서 별도의 서버인 것처럼 사용하는것
  • 리눅스를 사용해야함
  • 도커: 컨테이너를 생성하는 도구
  • 하드웨어 가상화 없이 커널 수준의 격리 기술을 제공하기 때문에 가상 머신에 비해 빠름
  • 게스트 os도 설치 안함
  • 쿠버네티스: 컨테이너를 배포, 관리하는 시스템

4. chroot

  • 특정 디렉토리를 '/'로 만드는것 즉 /root/newroot 가 존재하면 chroot로 '/' -> '/root/newroot'로 바꾸는것이며 '/root/newroot'가 '/'로 보인다
  • 그렇게 보이게 하고 싶다면 해당 응용프로그램이 '/root/newroot'내부에 존재해야함
  • 순서
    1. 디렉토리 생성
    2. 실행 파일 넣기
    3. 실행파일에 필요한 라이브러리 파일 넣기
    4. 실행하기

5. Namespace

  • 특정 프로세스에 대한 시스템 리소스를 논리적으로 격리하는 기능
  • 각 반의 출석부가 존재하는데 각반의 학생 번호마다 학생이 다른 것처럼 다르게하는것 대신 각각 반에는 누가 있는지 몰라야함? 이게 말이되는거임? 어케몰름 지나가면서 보는데 프로그램적 허용~
  • 시스템 콜
    1. clone(): 새로운 프로세스를 생성할때 부모 프로세스 네임을 복제해서 네임을 동일하게 연결
    2. unshare(): 새로운 프로세스를 생성할때 지정된 새로운 네임에 연결하는것
    3. setns(): 새로운 프로세스를 생성할때 이미 존재하는 네임에 연결하는것
  • Namespace 종류
    1. PID Namespace: PID를 분리하여 격리하여 관리, 새로 생성하면 1번부터 다시 시작 개별적으로 트리가 구성되어서 충돌 ㄴㄴ 6번에서 시작하면 6번이 1번이 되는것이니까!
      • 부모 pid
      • 새로운 프로세스 pid(unshare로 생성해서 다름)
    2. MNT Namespace: 마운트 포인트를 기본으로 격리하여 관리, 마운트 포인트가 해당 응용프로그램만 보이는것
      • 프로세스 생성하기 전 마운트
      • 생성후 마운트 연결확인
      • id가 다름
    3. UTS Namespace: uname으로 반환되는 정보중 hostname으로 격리하는것 hostname은 한서버에 하나뿐이지만 격리하면 별도로 가질 수 있음
      • hostname을 지정하면 이전의 프로세스와 hostname 다름
    4. IPC Namespace: 프로세스간의 통신, 데이터 교환을 격리하는 것, 얘는 잘모르겠당~
      • 암튼 다름 통신이 생성되어 있는 것과 안되어있는 것
    5. USER Namespace: 프로세스를 실행하면서 UID를 다르게 지정하여 격리하며 사용하는것, uesr01(UID:1000)이라는 유저가 격리되면서 user01(UID:2000)으로 들어갈수 있는것 0으로하면 루트로 접속
      • uid를 지정하면서 접속 하면서 기존의 프로세스의 uid가 새로운 프로세스에서는 root로
    6. NAT Namespace: 네트워크는 연결이고 컨테이너는 격리인데 왜 같이 있냐~ 라고 하지만 컨테이너 각각 네트워크를 가지게 된다, 각각 렌카드를 가지는 느낌, 하드웨어에서도 컨테이너마다 연결해주는 가상의 렌카드를 만들어줘야한다.
      • 얘는 내일하기로 했음

이후

오늘 뭔가 쓰는게 많이 보이지는 않는데
어려워! 다처음보니까 근데 모르겠어!
점심은 찜닭먹음

4/24 34일차

오늘 날씨 진짜 좋더라,,

오전

  • 어제 NAT Namespace를 하기로 했다
  • 순서
    1. 존재하는지 확인하고 추가 및 루프백 활성화
    2. 가상 인터페이스(veth) 생성
    3. guest 인터페이스 네임 스페이스 변경
    4. host 인터페이스 ip 추가
    5. guest 인터페이스 ip 추가
    6. ping으로 연결확인
    7. 삭제하기
      -끝!

1. Cgroups

  • 단일 프로세스 or 작업=task(프로세스 그룹)이라고 불리는 프로세스에게 자원 할당 및 제어 하는 커널 기능
  • 자원을 독점하지 못하게 할당하는것
  • 리눅스 기능이지만 도커가 빌려쓰는것
  • 가상파일시스템vfs의 디렉토리 표시되는 계층 구조로 cgroup 일부 기능은 부모속성을 상속
  • 제어방법
    • mount된 vfs의 디렉토리와 파일을 수동으로 편집
    • 패키지 형태로 제공되는 사용자 도구 사용
  • 자원 종류(cpu가 있따~)
  • 순서
    1. 먼저 cpu를 점유할 수 있는 for문을 생성
    2. 2가 아닌 1을 쓸거니까 바꿈

    • 점유 확인
    1. /sys/fs/cgroup/cpuset 에서 파일 생성
    2. 특정 cpu에서 실행하도록 지정
    3. cpu 가중치 설정하기 1개에서 사용하면 100에서 몇정도 쓰라고 하는것

오후

2. OverlayFS

  • AUFS가 있긴 하지만 요즘은 OverlayFS를 사용한다
  • 기존의 파일시스템은 삭제, 수정등 바로 가능했지만 OverlayFS는 그림그리는 어플처럼 레이아웃여러개 순서대로 위에서 보면 되는 느낌~
  • 그림으로 그리고싶지만 못그려,,
  • 레이어라는 개념으로 하나의 배경에서 각각의 프로그램의 변경점을 변경하지만 배경은 변화 하지않는다.
  • 실습
    1. 파일 디렉토리 생성
    2. 연결
    3. 확인
    4. 수정(머지만 수정되고 컨테이너에 수정사항만 나옴)
    5. 삭제

2. Docker

  • 컨테이너를 생성, 이미지 생성 등을 하는 프로그램

  • 호스트 운영체제가 최소한 3.10 버전 이상을 사용해야하니까 버전 확인

  • 설치하는 방법은 여러개가 있지만 패키지로 설치 안하고 스크립트로 했음 그게 요즘은 더편하데!, 버전까지 지정할수 있으니까

    1. 도커 구조

    • 도커 서버: 컨테이너들을 제공하는 곳
    • 도커 클라이언트: 컨테이너를 제공받는 곳
    • 이미지: 도커 컨테이너를 만들려고 하는데 컨테이너는 빈상자이다! 그안에서 실행해야하는 파일이 이미지!!
    • 컨테이너: 이미지를 실행시키는 것! 격리되어서 실행시키고 이미지를 기반으로 실행하는 것이다! 프로세서같은 느낌
    • 레지스트리: 이미지를 넣어두는 곳 push

    2. 이미지

    • 컨테이너 생성할 때 필요
    • 가상 머신을 생성할 때 iso와 비슷한것
    • 여러 개의 계층으로 되어있는 바이너리 파일로 존재 -> 컨테니언 생성하고 실행할때 읽기 전용으로 사용
    • 이름
    • 레지스트리: 도메인 이름
    • 저장소: 내이름
    • 이미지: 이미지 역활 이름
    • 태그: 버전, 식별번호

    3. 명령어

    • version: 버전확인 -> --version으로 더 많이씀 간단하게 나와서
    • info 실행 환경 상세 정보
    • system df: 디스크 사용량
    • run, rm 을 젤 많이 씀
    • create: 생성
    • ps: 컨테이너 목록 확인
      • comnamd가 중요해! PID=1 뭔지 알 수 있음
      • status 컨테이너 상태
      • 생성
    • start: 컨테이너 실행시작
    • stop: 종료

    4. run

    • 생성하면서 실행하기
    • 백그라운드로 실행하기 -> -d 실제로 실무에서는 백그라운드에서 실행하는 과정이 더많다고
    • 포그라운드로 실행하고 종료안하고 나가기 -> ctrl + pq 누르기
    • attach로 나간것 들어가기 접속하기
    • exec 실행중인 컨테이너에서 새로운 프로세스 실행
    • logs 로그가 나오는게 아니라 실행결과가 나오는것
    • top 프로세스 확인 할때 사용
    • workdir: 시작하는 디렉토리
    • env: 환경변수 지정하기 --env-file파일로도 선언가능
    • 환경변수 확인

이후

오늘 날씨가 너무좋아 근데 왜춥지? 20도인데?
점심에 엠브로가서 고추장불고기 먹음
그리고 동기분이 마실것 사주셨음!

4/25 35일차

금 요 일 좋 아
전 철 싫 어

오전

  • 어제 실행한 컨테이너 모두 제거하기
  • 현재 기동중이지 않은 컨테이너 삭제
  • prune

1. 컨테이너 명령어

  • restart: 컨테이너가 종료되면 어떻게 처리할지에 대한 규칙을 정하는 명령어
    • no: 종료되면 재구동 ㄴㄴ
    • always: 종료되면 계속 재구동
    • on-failure:n: 비정상 종료하면 재구동, 횟수도 설정가능
    • 비정상 종료해보기 (컨테이너를 내부에서 실행한 프로세스를 정지하기 2회 했음)
    • 3회 비정상 종료 다시 실행 안된다.
  • cpus: 컨테이너에서 사용하는 cpus 사용량 설정 1 -> 1코어
    • 50%만 사용하게
    • 컨테이너의 cpu의 총 사용량인것이라 컨테이너에서 여러 프로그램이라면 나눠씀
  • exec: 실행중인 컨테이너에서 pid=1이 아닌 새로운 프로세서를 실행하기
    • httpd로 실행했지만 exec로 bash를 실행해 입력이 가능하게 했음
    • 이미지에서 시작디렉토리 설정되어있을수 잇음
    • 내부에서 없는 명령어는 설치해서 사용할 수 있음 문제는 다운받는 명령어도 없어서 다설치해야하는데, 그럴거면 이미지를 새로 생성하는게 더좋음
    • exit해도 종료안됨, pid=1은 httpd라서 bash이 종료된다고 끝은 아니지
  • logs: 어제도 했지만 로그를 보는게 아니고 실행 결과를 보는것임
    • since=시간: 10초전부터 현재 까지
    • until=시간: 설정 시간 까지
    • t: 실행시간 정보 나옴
    • f: 실시간으로 나옴
  • stats: 사용량 실시간 확인
    • 현재 사용중인 실시간으로
    • no-stream: 한번의 실행결과만
  • top 실행중인 컨테이너 프로세스
    • 컨테이너의 내부의 프로세스 정보 맨위가 첫번째가 프로세스임(컨테이너 내부에서는 첫번째지만 밖에서 보면 아니라는것)
  • pause: 실행중인 일시정지
    • 죽은것도 아님 멈춘것! 이렇게 멈추면 어떤 작업도 못함
  • unpause: 일시정지한것을 다시 실행
    • 일시정지하고 다시 실행하기

오후

2. 컨테이너 명령어 왤케 많음

  • rm: 컨테이너 삭제
    • 컨테이너 실행중에는 삭제가 ㄴㄴ 근데 -f 옵션으로는 강제 종료
  • prune: 종료된 컨테이너를 전부 삭제하는것, 오늘 아침에 했음, 실행중인 것까지 모두 삭제해주세요 는 없음 하지만 방법이 있다
    • 이렇게 하면된다
    • 우리는 명령문이 너무 길어서 간단하게 alias로 설정해줬음, 실제로는 하면안된다!
  • rename: 이름 변경하기 컨테이너id는 변경ㄴㄴ
    -
  • cp: 컨테이너 복사하기 파일 복사하기
    • 외부의 파일을 컨테이너 내부에 복사하기
    • 내부에서 파일을 외부로 복사하기
  • diff: 변경된 이력 확인, A 추가, C 변경, D 삭제

2. 도커 볼륨

  • 컨테이너를 삭제하면 내부에 있는 데이터도 모두 삭제가 되기 때문에 필요하다.
  • bind mounts: 마운트 포인트 디렉토리를 먼저생성하고 를 컨테이너의 특정 디렉토리에 연결해서 컨테이너와 연결해서 데이터를 저장할 수 있도록 만듬 하지만 컨테이너가 많으면 관리가 어려움
  • 호스트의 특정 디렉토리를 참고하고싶을때도 사용가능
  • 저장위치가 중요하지않고 저장만하면된다. 볼륨 아니다 위치까지 중요하다 바인드 마운트

1. bind mounts 실습

  1. 디렉토리,파일 먼저 생성
  2. 컨테이너 생성 할때 마운트, 하고 확인하자
  • v 마운트 경로, :/할때 앞이 호스트 경로 :ro 는 readonly
  1. 파일 수정해보기
  2. 생성도 마찬가지다
  3. 컨테이너를 삭제하고 영구적으로 남아있는지 보자
  4. 똑같이 생성하면 어케되는지 봐보자 마운트해둔곳은 데이터가 남아있지만 경로 외에 생성한 데이터는 아까 삭제한 컨테이너와 같이 삭제되었다
  • 기존에 있는 디렉토리에 연결하면 호스트가 기준으로 호스트의 디렉토리 내용만 보이게 하는것
  • 그래서 기존에 있는 디렉토리에 연결하지 않는다

2. volume

  • 볼륨을 생성해두면 연결할때 이름면 넣으면 자동으로 연결할수 있음
  • 연결 위치는 지정해줘야함
  • 기존에 있는 디렉토리에는 연결하지 않는다.
  • 볼륨 있는지 확인 생성한적이 없어서 없긴해
  • 볼륨 자동 생성: 컨테이너 생성시 자동으로 생성 이름 식별이 어려워서 잘안씀
    1. 볼륨이랑 컨테이너 생성하고 컨테이너 내부의 파일 복사해두기
    2. 이름이 이렇게 자동으로 생성됨(16진수로)
    3. volume 자세하게 보기 inspect으로 확인 가능
    • mountpoint가 실제 저장위치 /var/lib/docker/volumes/자동생성된이름/_data
    1. 파일 저장확인
    2. 컨테이너 자세히 보기로도 볼륨의 마운트포인트, 권한 등을 볼수 있음
  • named volume 생성: 이름을 넣으면서 생성
    1. 생성하기
    • 자세하기 보기
    1. 사용해서 연결하기 -volumes-from vol_container
    2. 같은 볼륨을 다른 컨테이너에 연결해?
    • volumes-from 컨테이너명 -> 컨테이너명과 똑같은 볼륨을 사용하겠다
    1. 새로 생성한 컨테이너에서 변경하면 기존에 연결되어있는 컨테이너에서 확인하면 바뀔까?

      -> 동일한 볼륨을 사용할때는 이렇게 하면 된다.
  • 기존에 데이터가 있는 디렉토리에 볼륨을 지정한다면?
  • root에 연결했는데 원래 있어야할파일들이 없기때문에 프롬프트가 이상하게 나옴
  • 옵션에 따라 있을수 있음
  • -> volume-nocopy로 호스트에있는 볼륨에 연결되는 디렉토리에 파일있으면 복사를 할지않할지 지정하는 것
  • --rm 옵셥을 주면 종료하면 컨테이너도 삭제된다.

3. tmpfs

  • 메모리 위에 저장되는 볼륨이다 그래서 종료되면 삭제된다.
  • --mount type=tmpfs,destination=/updir
  • 생성했던 디렉토리의 내부 파일들이 정지를 했다고 해서 다 삭제 되었다.
  • restart도 마찬가지다

3. NFS로 데이터 공유로 저장하기

  • 미니프로젝트할때 db 데이터를 nfs서버에 저장하는 것처럼 볼륨을 저장하는걸로
  1. 서버가 2개이상 필요해서 복제해서 생성
  2. 노랑색이 NFS서버임 암튼 거기서 nfs-server설치
  3. 확인하기 위한 공유디렉토리 생성 및 파일 생성
  4. 다했으면 이제 볼륨을 사용할 서버에서 nfs common 설치 공유되는지 확인
  5. 볼륨 생성하면서 연결 --drver local인데 로컬처럼 공유디렉토리를쓰는것이니까 맞음
  6. 상세보기 볼륨의 지정까지 보임
  7. 컨테이너 생성하기 type nfs로하면됨
    • 아까 저장한 파일도 보이고 마운트도 되있는걸 확인할수 있음
  8. 컨테이너에서 파일 생성하면 nfs서버에서 확인가능하다.

4. 도커 네트워크

  • 컨테이너를 생성하면 내부 ip를 순차적으로 할당받는다 그래서 ip가 바뀔수도 안바뀔수도 있다. 1번 192.168.137.1 -> 2번 192.168.137.2 이렇게 한개씩 증가함
  • 컨테이너를 정지하면 ip를 반환한다.
    즉 1번을 하다가 정지하면 192.168.137.1은 아무도 안쓰는거임 -> 그래서 3번 컨테이너를 실행하면 192.168.137.1을 쓰는거임 -> 다시 1번을 실행하면 192.168.137.3으로 간다!!
  • 보면 알겠는데 따로 어케 보여줘야할지 모르겠네
  • 컨테이너 내부의 ip, 인터페이서 9번이란뜻
  • 호스트에서 ip를 보면 9번에 연결되있음
  • 외부와 직접적으로 연결을 할수 없기때문에 호스트에 연결해서 사용하는 것이다.

이후

오늘은 점심에 나주식당갔음
나는 비빔밥먹었다 뭔가뭔가 그랬음 옛날에 학교다닐때 동네 지하에 있는 식당같은 느낌이였음

7주차 후기

이번주에 도커를 하기 시작했는데 원래 기대하던 강의라서 그런지 흥미로웠음
근데 어렵긴해
그만큼 강사님이 알기 쉽게 설명해주시는데 그다음걸 하면 또 까먹음ㅋㅋㅋ
블로그 쓰면서 복습하는거지!
왜 이번주는 잠이 깨는거야~
암튼 이번주 도커도 재밌었다

profile
접니다

0개의 댓글