이 블로그는 최범균 님의 JPA 기초 강의를 듣고 작성한 블로그입니다.

일단 해보기 (jpa 3.0 기준)

JPA 특징

1. 애노테이션을 이용한 매핑 설정
   • xml 파일을 이용한 매핑 설정도 가능
2. String, int, LocalDate 등 기본적인 타입에 대한 매핑 지원
3. 커스텀 타입 변환기 지원
   • 내가 만든 Money 타입을 DB 칼럼에 매핑 가능
4. 벨류 타입 매핑 지원
   • 한 개 이상 칼럼을 한 개 타입으로 매핑 가능
5. 클래스 간 연간 지원 : 1 - 1, 1 - N, N - 1, N - M
6. 상속에 대한 매핑 지원

DB USER 생성

create database jpabegin CHARACTER SET utf8mb4;

CREATE USER 'jpauser'@'localhost' IDENTIFIED BY 'jpapass';
CREATE USER 'jpauser'@'%' IDENTIFIED BY 'jpapass';

GRANT ALL PRIVILEGES ON jpabegin.* TO 'jpauser'@'localhost';
GRANT ALL PRIVILEGES ON jpabegin.* TO 'jpauser'@'%'; 

create table jpabegin.user (
	email varchar(50) not null primary key,
	name varchar(50),
	create_date datetime,
) engine innodb character set utf8mb4; 

JPA 코드

@Entity DB 테이블과 매핑할 대상
@Table(name = "user") user 테이블과 매핑
public class User {
	@Id 식별자에 대응
	private String email;
	private String name;
	@Column(name = "create_date") create_date 칼럼과 매핑 칼럼이름과 필드 이름이 다를때 사용
	private LocalDateTime createDate;

일단 해보기 정리

1. 간단한 설정으로 클래스와 테이블 간 매핑 처리
2. EntityManager를 이용해서 DB 연동 처리
3. 객체 변경만으로 DB 테이블 업데이트
4. 쿼리 작성 x

https://www.youtube.com/watch?v=Zwq2McbFOn4&list=PLwouWTPuIjUi9Sih9mEci4Rqhz1VqiQXX&index=1 

Introduction to Containers and Kubernetes

기본 배포 방식 vs 가상화

기본 배포 방식

1. 애플리케이션을 배포하는 기본 방식은 실제 컴퓨터에 배포하는 것이었다.
2. 앱을 설치하려면 물리적 공간, 전원 냉각 장치, 네트워크 연결을 준비한 후 운영체제를 깔고 소프트웨어 종속 항목을 먼저 설치해야 한다.

기본 배포 방식의 문제점

1. 리소스 낭비가 크고 대규모 배포와 유지보수에 많은 시간이 소요된다.
2. 이동하기가 매우 어렵다.
3. 애플리케이션은 특정 운영체제에 맞게 빌드되었고 특정 하드웨어에 맞춰 빌드되는 경우도 있다.

가상화 이점

1. 가상화를 통해 여러 가상 서버와 운영체제를 동일한 물리적 컴퓨터에서 실행할 수 있다.
2. 하이퍼바이저는 소프트웨어 레이어로서 기본 하드웨어에서 운영체제의 종속성을 해소하여 여러 가상 머신이 하드웨어 하나를 공유할 수 있다.
3. 새 서버를 빠르게 배포할 수 있습니다.
4. 새 솔루션 배포 시간이 짧아집니다.
5. 가상 머신은 이미지를 만들어 이동할 수 있기 때문에 사용하는 물리적 컴퓨터의 리소스 낭비가 줄어들고 이동성이 향상된다.

VM의 문제점

1. 애플리케이션, 모든 종속 항목과 운영체제는 여전히 번들로 묶여 있습니다.
2. VM을 하이퍼바이저 제품 간에 이동하는 것은 쉽지 않다.
3. VM을 시작할 때마다 운영체제를 부팅하는 시간이 소요됩니다.
4. 단일 VM에서 여러 애플리케이션을 실행 시 문제점
   1. 종속 항목을 공유하는 애플리케이션이 서로 격리되지 않는 문제가 있다.
   2. 특정 애플리케이션의 리소스 요구사항 때문에 다른 애플리케이션에서 필요한 리소스를 확보하지 못할 수 있다.
   3. 특정 애플리케이션의 종속 항목 업그레이드로 인해 다른 애플리케이션이 실행 중지될 수 있습니다.
5. 위와 같은 문제를 엄격한 소프트웨어 엔지니어링 정책으로 문제 해결을 할 수 있다.
   1. 종속 항목은 종종 업그레이드가 필요하다.
   2. 애플리케이션 작동을 확인하는 통합 테스트를 추가할 수 있다.
   3. 종속 항목 문제가 새 장애를 일으키고 해결이 어려울 수도 있다.
   4. 애플리케이션 환경의 기본 무결성을 확인하기 위해 통합 테스트를 이용해야 하는 경우 개발 속도가 크게 저하된다.
6. 종속 항목을 잠그고 어느 애플리케이션에서도 이를 변경할 수 없도록 할 수 있지만 새 문제가 생깁니다.

VM 중심으로 이 문제를 해결하는 방법

1. 애플리케이션마다 전용 가상 머신을 실행하는 것 수십만 개 애플리케이션으로 확장하면 문제가 발생한다.
   1. 대규모 시스템의 경우 전용 VM은 중복적이며 낭비입니다.
   2. 전체 운영체제를 부팅해야 하기 때문에 VM은 시작하는 속도가 비교적 느리다.
2. 각 애플리케이션에서 고유 종속 항목을 유지 관리하고 커널이 격리되어 있으므로 애플리케이션끼리 성능에 영향을 미치지 않습니다.
3. 종속 항목 문제를 더 효율적으로 해결하려면 애플리케이션과 종속 항목 수준에서 추상화를 구현한다.
4. 전체 머신 또는 전체 운영체제가 아니라 사용자 공간만 가상화하면 됩니다.

컨테이너란?

• 사용자 공간은 커널 위에 있는 모든 코드이며 애플리케이션과 종속 항목을 포함합니다. 이것이 컨테이너를 만든다는 의미이다.
• 컨테이너는 단일 애플리케이션 코드를 실행하는 격리된 사용자 공간이다.

컨테이너의 장점

1. 운영체제 전체를 실행하지 않으므로 가볍다.
2. 기본 시스템 위에서 예약하고 패키징 하므로 매우 효율적이다.
3. 컨테이너는 아주 빠르게 만들고 종료할 수 있다.
4. 애플리케이션을 구성하는 프로세스만 시작 또는 중지하고 전체 VM을 부팅하거나 각 애플리케이션의 운영체제를 초기화하지 않기 때문입니다.
5. 시스템의 나머지는 신경 쓰지 않아도 된다.
   1. VM에서 최종 코드를 실행할 때 소프트웨어 종속 항목 즉 애플리케이션 런타임, 시스템 도구 시스템 라이브러리, 기타 설정에 신경 쓰지 않아도 됩니다
6. 가볍고 독립적이고 리소스 효율이 높으며 이동성이 우수한 실행 패키지이다.

개발자 관점 컨테이너 이점

1. 애플리케이션 중심으로 확장성 높은 고성능 애플리케이션을 제공하기 때문이다.
2. 컨테이너를 사용하면 개발자가 기본 하드웨어와 소프트웨어를 전제로 작업할 수 있다.
3. 모든 환경에서 동일한 컨테이너가 동일하게 실행된다.
4. 개발 프로세스가 빨라진다.
   1. 프로덕션 이미지를 기반으로 컨테이너를 점진적으로 변경하고 파일 복사 한 번으로 이를 빠르게 배포할 수 있습니다.
5. 컨테이너는 애플리케이션을 쉽게 빌드할 수 있다.
   1. 애플리케이션은 마이크로 서비스 설계 패턴 즉, 느슨하게 결합되고 세분화된 구성요소를 사용합니다.
   2. 이 모듈식 설계 패턴은 운영체제를 확장하고 애플리케이션의 구성요소를 업그레이드하면서도 전체 애플리케이션에는 영향을 주지 않습니다

컨테이너 설명

애플리케이션과 종속 항목을 '이미지'라고 합니다. 간단히 말해 컨테이너는 실행 중인 이미지 인스턴스입니다.

1. 컨테이너는 Linux 네임스페이스를 사용하여 애플리케이션에 제공할 항목인 프로세스 ID 번호, 디렉터리 트리, IP 주소 등을 제어합니다.
2. 컨테이너는 Linux cgroup으로 애플리케이션이 사용할 수 있는 CPU 시간, 메모리, I/O 대역폭 기타 리소스의 최대 사용량을 제어합니다.
3. 컨테이너는 유니온 파일 시스템을 사용하여 애플리케이션과 종속 항목을 간결한 최소 레이어 모음으로 효율적으로 캡슐화합니다.
4. 컨테이너 이미지는 여러 레이어로 구조화됩니다.

컨테이너 빌드

• 이미지 빌드에 사용하는 도구는 '컨테이너 매니페스트'라는 파일에서 안내를 읽어옵니다.
• Docker 형식의 컨테이너 이미지의 경우 이를 Dockerfile이라고 합니다.
• Dockerfile의 안내에 따라 컨테이너 이미지 내부 레이어가 지정됩니다. 각 레이어는 읽기 전용입니다. 이 이미지에서 컨테이너를 실행하는 경우 쓰기 가능한 임시 최상위 레이어도 생성됩니다.
• Dockerfile의 명령어 4개는 각각 하나의 레이어를 생성합니다.

Dockerfile 명령어

• FROM 문으로 기본 레이어를 공개 저장소에서 가져와 생성합니다.
• COPY 명령어로 새 레이어를 추가한다.
• RUN 명령어는 make 명령어를 사용하여 애플리케이션을 빌드하고 빌드 결과를 세 번째 레이어에 배치합니다.
• 마지막 레이어는 실행 시 컨테이너 내에 실행할 명령어를 지정합니다.
• Dockerfile을 작성할 때는 변경할 가능성이 가장 낮은 레이어에서 변경할 가능성이 가장 높은 레이어로 구성해야 합니다.
• 요즘은 배포 및 실행하는 컨테이너에 애플리케이션을 빌드하는 것은 권장하지 않습니다.
• 요즘은 애플리케이션 패키징에 다단계 빌드 프로세스를 이용하는데 이 경우 한 컨테이너에서 최종 실행 가능한 이미지를 빌드하고 다른 컨테이너에는 애플리케이션 실행에 필요한 항목만 포함합니다.

컨테이너 레이어

• 이미지에서 새 컨테이너를 만들면 컨테이너 런타임에서는 쓰기 가능한 레이어를 기본 레이어 위에 추가합니다. 이 레이어를 보통 '컨테이너 레이어'라고 합니다.
• 실행 중인 컨테이너에 대한 새 파일 쓰기, 기존 파일 수정 및 파일 삭제와 같은 모든 변경사항은 쓰기 가능하고 얇은 컨테이너 레이어에 기록됩니다. 각 컨테이너에는 쓰기 가능한 고유의 컨테이너 레이어가 있고 모든 변경사항이 이 레이어에 저장되므로 여러 컨테이너가 동일한 기본 이미지에 액세스 권한을 공유하면서도 자체 데이터 상태를 보유합니다.
• 이는 모두 임시 변경사항이므로 컨테이너가 삭제되면 이 레이어의 내용도 영구 삭제됩니다. 기본 컨테이너 이미지 자체는 변경되지 않은 상태로 유지됩니다. 애플리케이션을 설계할 때 이러한 컨테이너의 특징을 고려해야 합니다. 데이터를 영구적으로 저장하고 싶다면 실행 중인 컨테이너 이미지가 아닌 다른 곳에서 작업해야 합니다.
• 컨테이너를 실행하면 컨테이너 런타임에서 필요한 레이어를 가져옵니다. 업데이트할 때는 차이가 나는 항목만 복사하면 됩니다. 이렇게 하면 새 가상 머신을 실행하는 것보다 훨씬 빠릅니다.

Kubernetes란?

1. Kubernetes는 오픈소스 플랫폼으로서 컨테이너 인프라를 온프레미스 또는 클라우드에서 조정, 관리할 수 있습니다.
2. Kubernetes는 컨테이너 중심의 관리 환경이다.
3. Kubernetes는 컨테이너화 된 애플리케이션의 배포, 확장, 부하 분산, 로깅, 모니터링, 기타 관리 기능을 자동화합니다. 이러한 기능은 전형적인 Platform as a Service 솔루션 특징입니다.
4. Kubernetes는 Infrastructure as a Service 기능도 지원합니다. 예를 들어 다양한 사용자 환경설정과 구성 유연성을 지원합니다.
5. Kubernetes는 선언적 구성을 지원합니다 인프라를 선언적으로 관리하는 경우 일련의 명령어를 실행하는 게 아니라 달성하려는 상태를 설명하여 원하는 상태를 달성합니다.
6. Kubernetes는 배포된 시스템을 원하는 상태로 만들고 장애가 발생해도 상태를 유지합니다. 선언적 구성은 작업 부담을 덜어줍니다. 원하는 시스템 상태가 항상 문서화되어 있기 때문에 오류의 위험도 줄어듭니다.
7. Kubernetes는 명령형 구성도 지원하며 이 경우 명령어를 실행하여 시스템 상태를 변경합니다.
8. Kubernetes의 주요 장점 중 하나가 선언한 시스템 상태를 자동으로 유지할 수 있다는 점입니다.

Kubernetes의 기능

1. Kubernetes는 다양한 워크로드 유형을 지원합니다. Nginx, Apache 웹 서버 같은 스테이트리스(Stateless) 애플리케이션과 사용자 및 세션 데이터를 영구 저장할 수 있는 스테이트풀(Stateful) 애플리케이션을 지원하고 일괄 작업 및 데몬 태스크도 지원합니다.
2. Kubernetes는 리소스 사용률에 따라 컨테이너화 된 애플리케이션을 자동으로 수평 확장 및 축소할 수 있습니다.
3. 워크로드의 리소스 요청 수준과 리소스 한도를 지정하면 Kubernetes가 그대로 준수합니다.
4. Kubernetes는 이처럼 리소스를 제어하여 클러스터 내의 전반적인 워크로드 성능을 개선합니다.
5. 개발자는 Kubernetes를 통해 플러그인, 부가기능을 확장할 수 있습니다.
6. Kubernetes 선언적 관리 모델을 관리가 필요한 매우 다양한 다른 작업에 적용하고 있습니다.
7. Kubernetes는 오픈소스이므로 온프레미스 또는 GCP를 비롯한 여러 클라우드 서비스 제공업체 간 워크로드 이동성도 지원합니다.  따라서 Kubernetes를 어디든 배포할 수 있으며 공급업체의 제약 없이 워크로드를 자유롭게 이동할 수 있습니다.

Google Kubernetes Engine

1. GKE를 사용하면 GCP에서 컨테이너화된 애플리케이션을 위해 Kubernetes 환경을 배포, 관리, 확장할 수 있습니다. 구체적으로 GKE는 GCP 컴퓨팅 기능의 구성 요소이며 이를 통해 Kubernetes 워크로드를 클라우드에 손쉽게 배포할 수 있습니다.
2. GKE는 완전 관리형 서비스로 기본 리소스를 프로비저닝 할 필요가 없습니다. GKE는 컨테이너 최적화 운영체제를 사용합니다. Google이 관리하는 이 운영체제는 빠른 확장에 최적화되어 있으며 리소스 사용은 최소화합니다.
3. GKE를 사용하면 먼저 Kubernetes 시스템을 인스턴스 화하는데 이러한 시스템을 '클러스터'라고 합니다 GKE의 자동 업그레이드 기능을 사용 설정하면 클러스터가 자동으로 업그레이드되어 항상 최신 버전의 Kubernetes로 유지됩니다.
4. Identity and Access Management와도 통합되므로 계정 및 역할 권한을 사용해 액세스를 제어할 수 있습니다.
5. GKE는 Stackdriver Monitoring과 통합되어 애플리케이션 성능을 파악할 수 있게 해 줍니다.
   • Stackdriver는 Google Cloud 시스템으로 서비스, 컨테이너, 애플리케이션, 인프라를 모니터링하고 관리합니다.
6. GKE는 virtual private cloud 즉 VPC와 통합되며 GCP의 네트워킹 기능을 사용합니다.
7. GCP Console은 GKE 클러스터와 리소스에 대한 정보를 제공하며 여기에서 클러스터의 리소스를 확인, 검사, 삭제할 수 있습니다.
8. Kubernetes에는 대시보드가 포함되어 있지만 안전하게 설정하려면 상당한 노력이 필요합니다 하지만 GCP Console은 관리할 필요가 없는 GKE 클러스터 및 워크로드의 대시보드로 Kubernetes 대시보드보다 성능이 훨씬 우수합니다.

노드

1. GKE 클러스터 내에서 컨테이너를 호스팅 하는 가상 머신을 '노드'라고 합니다.
2. GKE의 자동 복구 기능을 사용 설정하면 서비스가 비정상 노드를 자동으로 복구합니다.
3. 각 클러스터 노드에서 정기적으로 상태를 확인합니다. 노드가 비정상 상태로 확인되어 복구가 필요하다면 GKE에서 노드를 드레이닝 즉, 워크로드를 정상적으로 종료하고 노드를 다시 생성합니다.

Compute Engine

1. GCP에서 실행되는 가상 머신을 제공합니다.
2. 사전 정의된 VM 구성을 선택할 수 있습니다. 이 과정이 개발된 시점을 기준으로 이러한 가상 머신의 크기는 3 테라바이트 이상의 메모리를 갖춘 최대 160개의 vCPU에 이릅니다 또한 성능 및 비용 요구사항과 정확히 일치하도록 맞춤 설정된 구성을 생성할 수도 있습니다.
3. 영구 디스크와 로컬 SSD라는 두 가지 주요 옵션을 제공합니다. 초당 입출력 작업 수가 매우 높은 로컬 SSD를 선택할 수도 있습니다. 영구 디스크는 최대 64 테라바이트까지 수직 확장할 수 있는 네트워크 스토리지를 제공하며 백업 및 이동성을 위해 영구 디스크의 스냅샷을 쉽게 만들 수 있습니다.
4. 자동 확장을 지원하는 전역 부하 분산기 뒤에 Compute Engine 워크로드를 배치할 수 있습니다.
5. Compute Engine은 관리형 인스턴스 그룹이라는 기능을 제공합니다.
   • 이 기능을 사용하여 수요를 충족하기 위해 자동으로 배포되는 리소스를 정의할 수 있습니다.
6. GCP는 초당 청구를 제공하여 Compute Engine 리소스 비용을 세부적으로 제어할 수 있습니다. 이러한 세부적인 제어 덕분에 일괄 처리 작업과 같이 짧은 기간에 컴퓨팅 리소스를 배포할 때 비용을 절감할 수 있습니다.
7. Compute Engine은 안전하게 중단될 수 있는 워크로드에 대해 가격이 훨씬 저렴한 선점형 가상 머신을 제공합니다.
8. Compute Engine을 사용하면 인프라를 완전히 제어할 수 있습니다
   • 운영체제를 맞춤 설정하고 여러 운영체제를 사용하는 애플리케이션을 실행할 수도 있습니다.
   • 애플리케이션을 다시 작성하거나 아무것도 변경하지 않아도 온프레미스 워크로드를 GCP로 쉽게 리프트 앤 시프트 할 수 있습니다.
9. 다른 컴퓨팅 옵션이 애플리케이션이나 요구사항을 지원하지 않을 때 선택할 수 있는 가장 좋은 옵션입니다.

App Engine

1. App Engine은 완전 관리형 애플리케이션 플랫폼입니다.
2. App Engine을 사용한다는 것은 실버 관리 및 구성 배포가 필요 없음을 뜻합니다. 개발자라면 배포에 대해 크게 걱정하지 않고 애플리케이션 빌드에 집중할 수 있습니다. 단순히 코드를 사용하기만 하면 App Engine에서 필요한 인프라를 배포합니다.
3. App Engine은 Java, Node.js, Python, PHP, C#, .Net, Ruby, Go 등 많이 사용되는 언어를 지원합니다. 컨테이너 워크로드를 실행할 수도 있습니다.
4. Stackdriver Monitoring, Logging, 디버깅 및 Error Reporting과 같은 진단도 App Engine과 긴밀하게 통합됩니다. Stackdriver를 실시간 디버깅 기능으로 사용하여 소스 코드를 분석하고 디버깅할 수 있습니다. Stackdriver는 Cloud SDK, Cloud Source Repositories, Intelligent, Visual Studio, PowerShell과 같은 도구와 통합됩니다.
5. App Engine은 또한 버전 제어 및 트래픽 분할도 지원합니다.
6. RESTful API는 개발자가 쉽게 작업하고 확장할 수 있으며 App Engine을 사용하면 쉽게 운영할 수 있습니다.

Google Kubernetes Engine

1. Kubernetes는 배포, 확장, 부하 분산, 로깅, 모니터링, 기타 관리 기능을 자동화합니다. Google Kubernetes Engine은 기능을 추가하고 다른 GCP 서비스와 자동으로 통합하여 GCP에서의 Kubernetes 관리를 확장합니다.
2. GKE는 클러스터 확장, 영구 디스크, 최신 버전의 Kubernetes로 자동 업데이트, 비정상 노드에 대한 자동 복구를 지원합니다.
3. GKE는 Cloud Build, Container Registry, Stackdriver Monitoring, Stackdriver Logging과의 통합 기능이 내장되어 있습니다. 온프레미스 클러스터로 실행되는 기존 워크로드는 GCP로 쉽게 이동할 수 있습니다 공급업체에 종속되지 않습니다.
4. GKE는 컨테이너화 된 애플리케이션, 클라우드 기반 분산 시스템, 하이브리드 애플리케이션에 매우 적합합니다.

Cloud Run

1. Cloud Run은 웹 요청 또는 Cloud Pub/Sub 이벤트를 통해 스테이트리스(Stateless) 컨테이너를 실행할 수 있는 관리형 컴퓨팅 플랫폼입니다.
2. Cloud Run은 서버리스입니다 모든 인프라 관리를 추상화하므로 애플리케이션 개발에만 집중할 수 있습니다.
3. Cloud Run을 사용하면 완전 관리형 또는 자체 GKE 클러스터에서 컨테이너를 실행할 수 있습니다.
4. Cloud Run을 사용하면 서버에 대해 걱정할 필요 없이 요청 또는 이벤트 기반 스테이트리스(Stateless) 워크로드를 실행할 수 있습니다.
5. 트래픽에 따라 거의 즉시 0에서 자동으로 확장 및 축소되므로 확장 구성을 걱정할 필요가 없습니다.
6. Cloud Run은 100밀리 초 단위로 계산하여 사용하는 리소스에 대해서만 비용을 청구합니다. 따라서 초과 프로비저닝 된 리소스의 비용을 지불할 필요가 없습니다.
7. Cloud Run은 100밀리 초 단위로 계산하여 사용하는 리소스에 대해서만 비용을 청구합니다 따라서 초과 프로비저닝 된 리소스의 비용을 지불할 필요가 없습니다.
8. HTTP 요청을 통해 전달되는 요청이나 이벤트를 수신 대기하는 스테이트리스(Stateless) 컨테이너를 배포할 수 있습니다.
9. Cloud Run을 사용하면 원하는 프레임워크와 도구를 사용하여 모든 언어로 애플리케이션을 빌드하고 해당 서버 인프라를 관리 및 유지할 필요 없이 단 몇 초 만에 배포할 수 있습니다.

GCP 클라우드 컴퓨팅 기본 속성

1. 컴퓨팅 리소스가 주문형 및 셀프서비스 방식으로 제공됩니다.
2. 클라우드 컴퓨팅 고객은 자동 인터페이스를 사용하므로 사람의 개입 없이 필요한 처리 능력, 스토리지 네트워크를 확보할 수 있습니다.
3. 어디서나 네트워크를 통해 리소스에 액세스 할 수 있습니다. 제공업체에서 대규모 풀의 리소스를 고객에게 할당하므로 고객은 규모의 경제가 주는 이점을 얻습니다.
4. 고객은 이러한 리소스의 정확한 물리적 위치를 파악하거나 신경 쓸 필요가 없습니다. 리소스는 탄력적으로 공급됩니다. 리소스가 추가로 필요하면 신속히 확보할 수 있고 적게 필요하면 축소할 수 있습니다.
5. 마지막으로 고객은 사용하거나 예약하는 만큼만 지불하면 됩니다 리소스 사용을 중단하면 지불도 중단됩니다.

GKE는 Google이 관리하는 클라우드 환경에서 컨테이너화 된 애플리케이션을 실행하며 사용자에게 관리 권한을 부여합니다.

컨테이너화는 이동성을 극대화하고 리소스를 효율적으로 사용할 수 있도록 코드를 패키지화하는 방식으로 Kubernetes는 컨테이너 내부에서 코드를 조정하는 방식으로 이해하면 됩니다.

GKE는 Compute Engine 기반 서비스이다.

Google Cloud Platform이 제공하는 서비스의 이면에는 다양한 리소스가 존재합니다.

1. 물리적 서버와 하드 드라이브 같은 물리적 애셋
2. 가상 머신이나 컨테이너 같은 가상 리소스

모두 Google의 글로벌 데이터 센터에서 관리됩니다.

Google Cloud는 멀티 리전, 리전, 영역을 통해 리소스를 제공합니다.

멀티 리전

1. 전 세계를 크게 세 지역으로 나눕니다. 아메리카, 유럽, 아시아 태평양

리전

1. 3개의 멀티 리전을 다시 나눈 것
2. 리전은 같은 대륙 내에서 독립된 지리적 위치입니다.
3. 리전 내에서는 네트워크 연결이 빠릅니다.
4. 일반적으로 95번째 백분위수에서 1밀리초 미만의 왕복 네트워크 지연 시간을 갖습니다.

영역

1. 리전은 최종적으로 영역으로 나뉩니다.
2. 영역이란 집중된 지리적 위치 내에 있는 GCP 리소스의 배포 위치를 뜻합니다.
3. 한 리전 내에 위치한 데이터 센터가 곧 영역이라고 볼 수 있습니다.
4. 하나의 영역이 반드시 하나의 데이터 센터인 것은 아닙니다.

Compute Engine 가상 머신 인스턴스는 특정 영역 내에 위치합니다. 

그 영역이 사용 불가 상태가 되면 가상 머신과 워크로드 또한 사용할 수 없게 됩니다.

GKE는 Compute Engine을 사용하므로 GKE 워크로드도 비슷한 영향을 받을 수 있습니다.

멀티 영역에 애플리케이션을 배포의 이점

1. 내결함성
2. 고가용성을 확보

세계 각지의 Google 데이터 센터는 Google 네트워크를 통해 연결됩니다.

Google 네트워크에 대한 설명

1. 사용자 앱을 포함한 모든 애플리케이션에 최대 처리량과 최소 지연 시간을 제공하도록 설계되었습니다.
2. Google 네트워크는 전 세계 90개 이상의 인터넷 교환 시설과 100개 이상의 접속 지점을 통해 공개 인터넷을 연결합니다.
3. 인터넷 사용자가 Google 리소스로 트래픽을 전송하면 Google은 지연 시간이 가장 낮은 에지 네트워크 위치에서 사용자의 요청에 응답합니다.
4. Google의 에지 캐싱 네트워크는 지연 시간을 최소화하도록 사용자 가까이에 콘텐츠를 배치합니다.
5. GKE를 비롯해 GCP에서 실행하는 애플리케이션도 이 에지 네트워크의 이점을 활용할 수 있습니다.

GCP와 리소스를 사용하면 리소스의 지리적 위치와 어느 수준에서 지정할지도 결정할 수 있습니다.

1. 영역 수준
   • 영역 리소스는 단일 영역 내에서 실행됩니다 따라서 해당 영역을 사용할 수 없게 되면 리소스 역시 사용할 수 없습니다. 간단한 예시로 Compute Engine 가상 머신 인스턴스와 영구 디스크를 들 수 있습니다. GKE의 구성요소의 하나인 '노드'도 영역 리소스에 해당합니다.
2. 리전 수준
   • 리전 리소스는 하나의 리전 내에 여러 영역에 걸쳐 실행됩니다. 리전 리소스를 사용하는 애플리케이션은 가용성을 높이기 위해 중복 배포될 수 있습니다. 이 전문 분야의 뒷부분에서 GKE를 사용하여 한 리전 내의 여러 영역에 리소스를 분산하는 방법을 알아보겠습니다. GCP 서비스인 Cloud Datastore도 이와 비슷하게 중복 방식을 통해 배포할 수 있습니다.
3. 멀티 리전 수준
   • 마지막으로 전역 리소스는 멀티 리전을 통해 관리할 수 있습니다. 전역 리소스는 애플리케이션의 가용성을 극대화합니다. 전역 리소스의 예시로는 HTTPS 부하 분산기와 virtual private cloud 즉 VPC 네트워크를 들 수 있으며 GKE 사용자도 이 리소스를 활용할 수 있습니다.

사용자가 사용하는 GCP 리소스는 위치와 상관없이 프로젝트에 속해야 합니다.

프로젝트란?

1. 항목을 구성하는 기본 수준으로 리소스 및 서비스를 생성, 사용할 때는 물론 결제, API, 권한 관리 시 기초가 됩니다.
2. 리전과 영역이 GCP 리소스를 물리적으로 구성한다면 프로젝트는 논리적으로 구성한다고 할 수 있습니다.
3. 프로젝트는 손쉽게 생성, 관리, 삭제가 가능하며 실수로 삭제할 경우 복구할 수도 있습니다.
4. 각 프로젝트는 고유한 프로젝트 ID와 프로젝트 번호로 식별됩니다.
5. 프로젝트 이름과 필터링을 위한 라벨을 정할 수 있습니다.
   • 라벨은 변경할 수 있지만 프로젝트 ID와 프로젝트 번호는 고정됩니다.
6. 프로젝트는 '폴더'라는 그룹으로 묶을 수 있습니다.
   1. 폴더를 사용하면 기업의 계층 구조를 반영하고 기업의 정책을 알맞은 수준에서 적용할 수 있습니다.
   2. 물론 폴더 내에 다른 폴더를 중첩할 수도 있습니다.
      1. 예를 들어 부서별 폴더를 만든 다음 각 부서의 폴더 내에 부서를 구성하는 팀별로 하위 폴더를 만들 수 있습니다.
      2. 각 팀의 프로젝트는 팀별 폴더에 속하게 됩니다. 모든 폴더는 하나의 조직에 포함됩니다.
      3. 조직은 GCP 리소스 계층 구조의 루트 노드입니다. 조직이 없더라도 GCP를 사용할 수는 있지만 조직은 무척 유용합니다.
      4. 조직을 이용해 기업 전반에 적용되는 정책을 설정할 수 있다. 또한 폴더를 사용하려면 조직이 필요합니다 GCP 고객이라면 이미 조직이 있을 것입니다. 그렇지 않다면 Google Cloud ID를 통해 무료로 만들 수 있습니다.
      5. 조직에는 고정 조직 ID와 변경할 수 있는 표시 이름이 있습니다. GCP 리소스 계층 구조는 조직 내 여러 부서와 팀의 리소스를 관리할 수 있도록 도와줍니다.
      6. 신뢰 경계와 리소스 격리를 구현하는 계층 구조를 정의할 수도 있습니다.
         1. 예를 들면 인사팀 직원에게 데이터베이스 서버 삭제 권한이 필요할까요? 엔지니어에게 직원 급여 데이터베이스를 삭제할 권한이 있어야 할까요? 둘 다 그렇지 않을 것입니다. Cloud IAM이라고도 하는 Cloud Identity and Access Management는 사용자가 사용하는 모든 GCP 리소스에 세부적인 액세스 제어를 가능케 합니다.
         2. IAM 정책을 정의하면 리소스의 사용자 액세스 제어가 가능합니다. 사용자가 선택한 수준에서 적용한 정책은 낮은 수준으로 상속됩니다. 예컨대 조직 수준에서 IAM 정책을 적용했다면 해당 조직 내의 폴더, 프로젝트 리소스까지 정책이 모두 적용됩니다.
         3. 계층 구조의 보다 낮은 수준에서 정책을 적용하면 추가 권한을 부여할 수 있습니다. 반면, 결제는 프로젝트 수준에서 누적됩니다. 대부분의 GCP 고객이 가진 리소스 계층 구조는 인사 조직도와 비슷하며 프로젝트 결제는 비용 센터 구조와 비슷합니다.
         4. 리소스 계층 구조가 중요한 이유는 GCP의 공유 보안 모델 때문입니다.
            1. 온프레미스 인프라에 애플리케이션을 구축할 경우 사용자가 스택 전체의 보안을 책임져야 합니다.
            2. 하드웨어와 하드웨어가 위치한 프레미스의 물리적 보안 디스크의 데이터 암호화 네트워크 무결성 애플리케이션에 저장된 콘텐츠 보호까지도 포함합니다.
            3. 하지만 애플리케이션을 GCP로 이전하면 Google에서 하위 레이어의 보안을 담당합니다. 하드웨어와 프레미스의 물리적 보안이나 디스크의 데이터 암호화 물리적 네트워크의 무결성 등이 포함되죠
            4. Google은 규모가 큰 만큼 대부분의 고객이 자체적으로 구현할 수 있는 것보다 안전하게 이러한 레이어를 보호할 수 있습니다. 데이터 보안을 비롯한 보안 스택의 상위 레이어는 여전히 사용자의 책임입니다.
            5. Google이 제공하는 도구는 사용자가 이러한 레이어에서 정의하는 정책을 구현하는 데 도움이 됩니다. 앞서 살펴본 리소스 계층 구조는 이러한 도구 중 하나이며 Cloud IAM 역시 마찬가지입니다.

GCP 결제

1. GCP 프로젝트 수준에서 설정합니다.
2. GCP 프로젝트를 정의할 때 결제 계정을 연결해야 합니다.
3. 결제 계정에서 사용자는 지불 옵션을 비롯한 모든 결제 정보를 설정합니다.
4. 결제 계정은 하나 이상의 프로젝트에 연결할 수 있습니다.
5. 결제 계정을 연결하지 않은 프로젝트는 무료 GCP 서비스만 사용 가능합니다.
6. 결제 계정은 매월 또는 기준액 도달 시 자동으로 청구 및 인보이스 되도록 설정할 수 있습니다.
7. 결제 하위 계정을 설정하면 프로젝트 결제를 분리할 수 있습니다.
8. GCP 서비스를 재판매하는 GCP 고객들은 재판매 고객별로 하위 계정을 사용하기도 합니다.

GCP 요금에 대한 걱정을 해결하는 세가지 유용한 도구

1. 예산 및 알림
   • 결제 계정 수준 또는 프로젝트 수준에서 예산을 정의할 수 있습니다.
   • 알림을 설정하면 비용이 예산 한도에 근접했을 때 알림을 받을 수 있습니다.
   • 예를 들면 예산 한도가 2만 달러이고 알림을 90%로 설정했다면 비용이 기준액이나 1만 8천 달러에 도달했을 때 알림을 받게 됩니다. 알림에 대한 응답으로 웹 훅이 호출되도록 설정할 수도 있으며 이 웹 훅을 사용하여 결제 알림을 기반으로 자동화를 제어할 수 있습니다. 예를 들어 결제 알림이 발생하면 리소스를 종료시키는 스크립트를 트리거하거나 웹 훅을 사용해 팀에 장애 신고를 제출할 수도 있습니다.
2. 결제 내보내기에서 보기
   • 외부 분석 검색이 손쉬운 곳에 결제 세부정보를 저장할 수 있습니다 BigQuery 데이터 세트나 Cloud Storage 버킷을 쓸 수 있다.
3. 보고서 보기
   • 보고서는 콘솔의 시각적 도구로 프로젝트 또는 서비스를 기준으로 지출을 모니터링할 수 있습니다.

GCP에 구현된 할당량은 예기치 못한 추가적인 결제 청구를 제한합니다.

할당량

1. 오류나 악성 공격으로 인해 리소스를 과소비하는 것을 방지하기 위해 설계되었다.
2. GCP 프로젝트 수준에서 적용됩니다.

할당량에는 두 가지 유형이 있다.

1. 비율 할당량
   • 특정 시점을 기준으로 재설정됩니다.
   • GKE 서비스는 기본적으로 GCP 프로젝트에서 API에 보내는 호출을 100초당 1천 건으로 제한하는 할당량을 구현하며 100초가 지나면 한도가 재설정됩니다.
   • 여기서 중요한 점은 GKE에서 실행되는 애플리케이션에서 받는 호출의 비율이 아닌 GKE 클러스터 자체에서 받는 호출을 제한하는 방식이라는 점입니다.
   • 일반적으로 그처럼 짧은 시간 안에 많은 호출을 보내는 일은 흔치 않으므로 할당량을 통해 오류성 행동을 차단하는 데 도움이 됩니다.
2. 배정 할당량
   1. 프로젝트 내에서 보유할 수 있는 리소스 수를 제어합니다.
   2. 배정 할당량은 시간이 지나도 재설정되지 않으므로 할당량이 넘지 않도록 리소스를 해제해야 합니다.
   3. 예를 들면 기본적으로 각 GCP 프로젝트는 VPC 네트워크 또는 virtual private cloud를 5개 이상 보유할 수 없도록 할당량이 적용됩니다.
   4. 할당량은 모든 프로젝트에 똑같이 적용되지 않습니다
      • 모든 프로젝트가 같은 할당량으로 시작되지만 Google Cloud 지원팀에 요청하면 일부 프로젝트의 할당량을 늘릴 수 있습니다.
      • 일부 할당량은 프로젝트 사용에 따라 자동으로 증가하기도 합니다.
      • GCP Console을 사용해 일부 프로젝트의 할당량을 줄일 수도 있습니다.
      • 모든 GCP 고객에게 고정되는 할당량도 일부 있습니다. 어떤 경우든 GCP 할당량은 고객에게 혜택을 주는 한편 예기치 않은 사용량 급증을 줄여 GCP 사용자 커뮤니티를 보호하는 역할을 합니다.

GCP와 상호작용하는 방법은 네 가지입니다

1. Google Cloud Platform Console
   • GCP Console은 웹 기반 그래픽 사용자 인터페이스로 GCP 리소스를 관리할 수 있습니다.
   • 간단한 마우스 클릭만으로 일반적인 작업을 수행할 수 있습니다.
   • 명령어를 외우거나 오타를 걱정할 필요가 없다.
   • GCP 프로젝트와 리소스를 가시적으로 파악하기도 용이합니다.
   • 웹브라우저로 console.cloud.google.com에 접속하여 GCP Console에 로그인하면 됩니다.
   • 왼쪽 상단의 탐색 메뉴 버튼을 통해 모든 GCP 서비스에 액세스 할 수 있습니다.
2. Cloud Shell
   • 사용 중인 머신에서 Cloud SDK 설치가 어려운 경우 사용한다.
   • Cloud Shell을 사용하면 브라우저에서 직접 명령줄을 통해 클라우드 리소스에 액세스 할 수 있습니다.
   • Cloud Shell을 사용하면 Cloud SDK 등의 도구를 로컬에 설치하지 않아도 손쉬운 프로젝트 및 리소스 관리가 가능합니다.
   • Cloud SDK, gcloud, kubectl 명령줄 도구와 그 외 유틸리티는 완전히 인증되어 있고 항상 최신 상태로 사용할 수 있습니다.
   • Cloud Shell은 어떻게 이것이 가능할까?
     • 비용이 없는 Compute Engine 가상 머신 인스턴스를 사용해 빌드되었기 때문입니다.
   • Cloud Shell 가상 머신은 단기적입니다. 사용자가 상호작용을 멈추면 작동을 중단하며 사용자가 Cloud Shell에 다시 진입하면 작동을 다시 시작합니다. 따라서 Cloud Shell에서 프로덕션 웹 서버를 실행하지 않는 것이 나을 수 있습니다.
   • 새 Cloud Shell 세션을 시작할 때마다 5GB의 영구 디스크 스토리지도 연결됩니다.
   • 또한 웹 미리보기 기능이 탑재되어 있으며 GKE 리소스를 비롯한 GCP Console 프로젝트 및 리소스에 대한 액세스 인증도 기본적으로 제공합니다.
   • Cloud Shell 코드 편집기는 웹브라우저에서 Cloud Shell 환경 내 파일을 실시간으로 편집하는 도구입니다.
   • Cloud Shell 명령 프롬프트에서 텍스트 편집기를 사용할 수도 있습니다.
   • 코드 우선 애플리케이션 또는 컨테이너 기반 워크로드를 작업할 때 무척 편리합니다. 변경사항을 다운로드, 업로드하지 않아도 간편하게 파일을 편집할 수 있기 때문이죠
3. Cloud SDK Cloud Console 모바일 앱
   • Google Cloud SDK를 다운로드하고 원하는 컴퓨터에 설치할 수도 있습니다.
   • Cloud SDK는 Google Cloud Platform용 명령줄 도구 집합을 포함하며 특히 이 과정에서 자주 사용할 gcloud 및 kubectl 명령어가 포함되어 있습니다.
   • gsutil 및 bq 유틸리티도 포함되어 있습니다.
   • 이러한 도구는 대화형으로나 자동화 스크립트에서 사용할 수도 있습니다.
   • Cloud SDK에는 다양한 프로그래밍 언어를 위한 클라이언트 라이브러리도 포함되어 있습니다
4. REST 기반 API
5. iOS와 Android에서 사용할 수 있는 Cloud Console 모바일 앱
   • 가상 머신 관리 가상 머신 로그 조회 프로젝트의 최신 결제 정보 확인 예산을 초과하는 프로젝트에 대해 결제 알림 받기
   • 커스텀 그래프를 설정하여 CPU 사용량과 네트워크 사용량 초당 요청 수, 서버 오류와 같은 주요 항목 표시 등이 있습니다

컴퓨팅 옵션

centos 파일형식 .rpm

소스 코드를 이용한 관리

./configure 컴퓨터의 환경 설정 파일

• 소스 코드 파일을 컴퓨터의 환경에 맞게 컴파일을 할 수 있게 환경을 설정해준다.

make

• 환경설정 파일로 컴파일을 수행한다.
• 소스 코드 파일을 실행파일로 만드는 과정

make install

• 설치한 파일을 올바른 위치에 가져다 놓는 과정을 거친다.

인터넷 저장소를 이용한 관리

레파지토리

설치

• yum install [패키지명] (* : 관련 패키지 모두를 설치한다) : 의존성이 있는 파일을 설치한다.

삭제

• yum erase [패키지명]

업그레이드

• yum upgrade [패키지명]

로그

운영 체제나 다른 소프트웨어가 실행 중에 발생하는 이벤트나 각기 다른 사용자의 통신 소프트웨어 간의 메시지를 기록한 파일 로그를 기록하는 행위는 로깅이라고 한다.

/etc/rsyslog.conf

형식

• [Facility].[Level] [Action]

Facility

• kern : 커널이 발생한 메시지
• user : 사용자 프로세스
• mail : mail 시스템 관련 서비스
• daemon : telnetd, ftpd, httpd과 관련된 서비스
• auth : 로그인과 같은 인증 관련 서비스
• syslog : syslog 관련 서비스
• cron : 예약 작업 관련 서비스, crond, atd
• * : 모든 서비스를 의미

Level

• emerge(블루스크린, 커널, 패닉) : 일반적으로 모든 사용자에게 전달되는 패닉 상황
• alert : 시스템 DB에 손상 등 즉시 수정해야 되는 상황
• crit : 하드 장치 오류 등 중대한 상황에 대한 경고
• err : 하등 장치 이외의 오류
• warning : 경고 메시지, 무시해도 됨
• notice : 특별한 처리가 필요할 수 있는 비 오류 상황
• info : 정보 메시지
• debug : 프로그램 개발 또는 테스트할 때 사용
• none : 로그로 기록 X

NFS

NFS란?

• 네트워크 파일 시스템
• 서버에서 공유한 디렉터리를 마치 로컬 시스템의 장치처럼 이용할 수 있게 개발된 파일 시스템
• 전통적인 유닉스 환경에서는 오랫동안 네트워크에서 자료를 공유하는 방법으로 사용
• NFS 서버가 디렉터리를 공유하면 NFS 클라이언트가 공유한 디렉터리를 마운트 해서 사용

/etc/exports

• 공유할 디렉터리 지정 파일
• [공유해주고 싶은 특정 디렉터리] [이 디렉터리를 이용할 수 있는 네트워크 대역 설정] [(이용하는 사람의 권한)]
• 다양한 공유 설정 옵션

/etc/sysconfig/nfs

• 포트 설정 파일

마운트

• 원격지의 파일 시스템
• mount [IP주소]: [폴더] [폴더]

nfsnobody

• NFS 클라이언트의 권한

데이터 백업과 복구의 개념

• 언제 발생할지 모르는 사고를 대비해 반드시 해야 할 작업이 ‘백업’
• 기존의 폴더 또는 파일을 다른 안전한 장소에 보관하는 것
• Windows Server에서는 자체적으로 백업 기능을 제공
• 백업은 별도의 하드디스크나 다른 컴퓨터의 공유 폴더에 하는 것이 필수
• 최근에는 서버와 멀리 떨어진 원격지에도 백업(클라우드)
• 복구는 삭제된 일부 폴더만 복구할 수도 있고, 볼륨 전체를 복구할 수도 있다.

백업의 종류

전체 백업

• 데이터 전체를 백업하는 것
• 시간이 오래 걸리고 백업할 때마다 중복된 데이터도 백업하기 때문에 디스크 공간이 많이 필요
• 가장 최근에 전체 백업을 복구하면 가장 최근의 데이터로 복구됨

증분 백업

• 이전에 수행한 백업으로부터 변경된 데이터만을 백업하는 것
• 데이터의 중복이 없고 용량을 많이 차지하지 않는다.
• 복구할 때는 전체 백업부터 증분 백업한 데이터를 순서대로 복구해야 최신 데이터를 복구할 수 있다.

차분 백업

• 이전에 수행한 전체 백업을 기준으로 변경된 데이터만 백업하는 것
• 전체 백업을 복구하고 가장 최근에 차분 백업을 복구하면 가장 최근의 데이터로 복구됨

tar를 이용한 전체 백업

• tar zcvpf [아카이브 이름] - -exclude=[예외] /
• exclude 옵션을 이용하여 백업 파일이 저장되는 경로는 제외한 나머지 / 전체를 백업한다.

tar를 이용한 증분 백업

• tar zcvpf [아카이브 이름] -g [리스트 파일 이름] [경로]
• -g 옵션을 이용하면 리스트를 만들어 백업 정보를 따로 저장해준다.
• -p 옵션을 이용하면 기존의 파일 시스템의 권한 정보를 그대로 유지한다.

tar를 이용한 복구

• tar zxcpf [아카이브 이름] -C [복구할 경로] -g [리스트 파일 이름]
• -C 옵션을 이용해서 아카이브 및 압축을 해제하면 특정 경로는 지정해서 해당 경로에 풀 수 있다.

dump를 이용한 백업

• dump [옵션]f [백업 장치] [백업 대상]
• 0 : 전체 백업
• -1 ~ 9 : 증분 or 차분 백업(자신보다 낮은 레벨 중 가장 가까운 레벨의 내용과 비교해서 변환 내용만 백업)
• -파일 시스템 단위로 백업

restore를 이용한 복구

• restore -rvf [백업 파일 or 장치]
• 작업 경로를 복구하길 원하는 경로로 이동 후 명령어 실행
• 복구 명령어를 실행하면 작업 디렉터리에 restoresymtable 파일이 생성
• 해당 파일은 증분 복구와 복구 사이의 진행 정보 등이 저장되어 있음
• 따라서 증분 백업을 모두 복구하기 전에 삭제 x
• 복구가 끝나면 모두 삭제

dd를 이용한 백업

• dd if=[백업할 장치] of=[저장할 위치] [bs=[크기] count=[숫자]]
• 블록 크기와 카운트를 지정하지 않으면 디스크 장치 단위로 백업 및 복구
• 블록 크기와 카운트를 지정하면 해당 용량만큼만 백업 및 복구 또는 복사

네트워크 설정

• 리눅스에서는 ifconfig 윈도우에서는 ipconfig
• ifconfig [장치명] [IP주소] netmask [서브넷 마스크]

route 명령어

route add default gw [GW 주소]

dhclient [장치명]

• /etc/sysconfig/network-script/ifcfg-ens33 파일로 설정
• ifcfg-ens33 파일에 BOOTPROTO=dhcp로 바꾼다.  static으로 설정하면 ip 주소를 수동으로 할당하고 dhcp로 설정하면 dhcp가 자동으로 할당
• ONBOOT=yes로 바꾼다. 부팅될 때 또는 서비스가 실행될 때 이 파일을 적용시킨다.
• BOOTPROTO를 static으로 바꾸면 파일에 IPADDR=[주소] NETMASK=[서브넷] GATEWAY=[주소] DNS1=[주소]를 추가로 설정해야 된다.

단일 작업 스케줄링

at [시간]

• at > 실행할 명령어 Ctrl + D(종료)
• at -l : 작업 조회할 때
• at -r [작업 번호] : 작업 삭제할 때

반복 작업 스케줄링

작업 예약할 때

• crontab -e

명령어 실행하면 편집기가 실행되고 편집기를 이용하여 내용을 작성

작업 삭제할 때

• crontab -r 
• 문서 들어가서 내용 삭제해도 된다.

스케줄링 접근제어

블랙리스트 방식

• at.deny, cron.deny
• 우선 모두 허용하고 리스트에 있는 특정 사용자들만 거부하는 방식

화이트리스트 방식

• at.allow, cron.allow
• 우선 모두를 거부하고 리스트에 있는 특정 사용자들만 허용하는 방식
• 작업 스케줄링 접근제어 파일은 관리자가 따로 생성해주어야 한다.

블랙리스트와 화이트리스트 모두 사용하는 경우 화이트리스트 방식이 우선시된다.

디스크 추가부터 사용하기까지 과정

ex4의 파일 시스템 구조

mkfs [이름]

• 파일 시스템 생성

마운트

특정 디렉터리와 특정 장치를 연결한다.

mount [옵션] [장치] [마운트 포인트]

[옵션]

• -t : 특정 파일시스템의 종류를 지정

[장치]

• 마운트 포인트와 연결할 장치를 지정, 일반적으로 파일 시스템을 생성한 파티션이 온다.

[마운트 포인트]

• 특정 디렉터리를 지정, 해당 디렉터리로 접근 시 지정한 장치로 이동됨

마운트 해지

umount [장치] or [마운트 포인트]

/etc/fstab

자동 마운트 설정 파일, 재부팅하면 mount 설정한 정보들이 다 지워진다.

슈퍼블록 복구 명령어

fsck -b [백업 블록 번호] [복구할 장치]

ex) fsck -b 8193 -fy /dev/sdf1

리눅스의 전통적인 부팅 과정

부팅 메뉴 파일

• /boot/grub2/grub.cfg

커널 이미지 파일

• vmlinuz

부팅할 때 나오는 메시지

• /var/log/boot.log

런레벨

시스템의 상태를 나타내는 값

• 런 레벨은 숫자 또는 문자로 표현된 시스템의 상태
• 런 레벨은 서비스와 사용자가 사용할 수 있는 자원들에 대해 정의하고 있음

런레벨 관련 명령어

• who -r : 현재 및 이전 런레벨을 확인하는 명령어
• init [런레벨] : 런 스크립트를 실행시키는 명령어

시스템 부팅 관련 명령어

• shutdown : rc 스크립트를 실행, init 명령어와 비슷한 기능을 수행, init과는 다르게 로그인 중인 모든 사용자에게 종료 시기를 알려준다.
• shutdown -r : 재부팅
• shutdown -h : 종료
• shutdown -t : 시간 지정
• halt, poweroff : rc0 스크립트들을 실행하지 않으므로 해당 프로세스가 있으면 문제가 발생할 수도 있다.
• reboot : 기본적으로 시스템을 런레벨 3으로 설정하면서 시스템을 즉시 종료시킨다. rc0 스크립트들을 실행하지 않으므로 해당 프로세스가 있으면 문제가 발생할 수도 있다.

systemd

• 리눅스를 부팅하면 커널이 가장 먼저 실행시키는 프로세스
• 기존의 리눅스는 가장 먼저 init 프로세스를 실행하고 init 프로세스가 필요한 다른 프로세스를 실행
• 기존의 init 프로세스는 단계적으로 런 레벨을 올려가며 해당 런 레벨의 rc스크립트를 차례대로 실행
• 하지만 init은 아주 오래전 리눅스에서부터 사용하던 아주 오래된 프로세스였고 이에 계속해서 기능이 추가되면서 프로그램들이 복잡해지다 보니 효율 또한 떨어지게 됐다.
• 이에 systemd는 init의 단점을 보안하며 기존 리눅스의 의존성을 해치지 않도록 개발되었다.
• systemd는 가능한 한 병렬로 시작 프로그램들을 실행시키는 것만으로 부팅 속도를 끌어올리고, 프로그램 실행을 위한 파일로는 쉘 스크립트가 아니라 service라는 systemd 만의 unit을 통해 체계적이면서 가독성이 좋도록 계발되었다.
• systemd는 단지 init 뿐만 아니라 다른 프로그램들의 기능마저 대체
• 네임서버 주소를 설정하는 resolv.conf의 자리를 systemd-resolved가 대체, DHCP 서버에서 IP를 받아와서 네트워크 인터페이스에 설정하는 dhcpcd의 자리를 systemd-network가 대체
• systemd는 전체 시스템을 시작하고 관리하는 데 유닛이라 부르는 구성 요소를 사용
• systemd는 관리 대상의 이름을 ‘서비스 이름, 유닛 종류'의 형태로 관리
• 유닛은 같은 이름과 종류로 구성된 설정 파일과 동일한 이름을 사용

유닛 기능 예

systemd를 제어하는 명령어

systemctl [옵션] [명령] [유닛 이름]

옵션

• -a : 상태와 관계없이 유닛 전체를 출력한다.
• -t [유닛의 종류] : 지정한 종류의 유닛만 출력한다.

명령

• start : 유닛을 실행한다.
• stop : 유닛을 정지한다.
• reload : 유닛의 설정 파일을 다시 읽어온다.
• restart : 유닛을 재시작한다.
• status : 유닛의 현재 상태를 확인한다.
• enable : 부팅 시 유닛을 자동으로 시작되도록 설정한다.
• disable : 부팅 시 유닛이 자동으로 시작되지 않도록 설정한다.