Blue Peach

GitHub Action 

: 깃헙에서 제공하는 CI/CD 및 자동화 서비스로 깃헙 레파지토리에서 발생하는 이벤트에 따라 워크플로우를 정의하고 이틍 통해 소트프웨어 빌드, 테스트, 배포 등을 자동으로 수행할 수 있다. 

1. 깃헙에 업로드한 걸 로컬 컴퓨터에 Clone
2. 코드를 수정해서 기능을 변경 또는 추가
3. 깃헙에 Push
4. CI 서버에서 자동으로 우분투 설치, JDK 설치, 코드 다운로드, 코드 테스트, build
5. 정상이면 배포

CI 서버를 사용하기 위한 스크립트 deploy.yml 파일 작성

===> 프로젝트 이름에 main 브랜치에 푸시

===> 여러 작업은 'jobs' 섹션에서 정의하고 각 작업은 'steps'로 구성된다. steps에는 워크플로의 각 단계에 해당하는 작업을 정의한다.

== uses : actions/checkout@v3 (actions 라이브러리에서 제공하는 명령어로 먼저 저장소를 체크아웃해준다.)

== uses : actions/setup-java@v3 (actions 라이브러리 에서 제공하는 명령어로  java 설치)

== run : chmod + x ./gradlew (gradlew 파일 권한 부여)

===> 한국시간으로 시간 설정

===> run : | 은 여러 줄로 명령어를 작성하겠다는 의미

mkdir deploy : deploy 파일 생성

cp build/libs/*.jar deploy/application.jar : build/libs/*.jar에서 생성된 jar 파일을 deploy/application.jar에 복사

cp procfile deploy/procfile : procfile를 deploy/procfile에 복사

cp -r .ebextensions deploy/.ebextensions : ebextensions 폴더를 deploy.ebextensions 폴더로 복사

(엘라스틱 빈스톡의 .ebextensions 폴더가 프로젝트의 특정 디렉토리로 정리되어 배포를 위한 설정 파일들이 별도의 위치에 저장될 때 사용할 수 있는 명령어)

cp deploy && zip -r deploy.zip : 두 개의 명령어를 사용하여 실행하려는 듯한 구문이지만, 명령어 간의 &&로 연결되어 첫 번째 명령어가 성공하면 다음 두 번째 명령어가 실행되도록 하는 것.

[K-디지털] AWS 리눅스 기반 클라우드 데브옵스 기초 실무 과정 참고하며 작성하였습니다.

롤링 

: 여러 컴퓨터 과학 및 소프트웨어 배포 컨텍스트에서 사용되며, 일반적으로 연속적이고 부드러운 업데이트 또는 배포를 의미한다. 

롤링 배포 정책 

1. 한 번에 모두

: 모든 서버 또는 인스턴스에 대해 동시에 새로운 버전을 배포하는 전략

===> 모든 서버가 동시에 업데이트되므로 배포 시간이 매우 짧지만, 모든 서버가 동시에 다운될 가능성이 있어 가용성에 영향을 줄 수 있다. 오류가 발생하면 모든 서버에 동시에 영향을 미칠 수 있다. 

2. 추가 배치 (무중단)

: 일부 서버를 먼저 업데이트하고, 그 후 추가 배치를 통해 나머지 서버를 업데이트하는 전략

===> 새로운 버전이 일부 서버에서 검증된 후에 전체로 확장된다. 이는 가용성을 높이며 롤링 업데이트의 안전성을 유지하는 방법이다. 배포하는 과정에서 한 개의 EC2에서 에러가 발생할 경우 롤백이 진행되는데, 이때 한 개의 EC2의 롤백이 나닌 전체 EC2의 롤백이 진행되기 때문에 자원이 많이 소요된다. 

3. 변경 불가_블루/그린 (무중단)

: 새로운 버전의 소프트웨어를 포함한느 새로운 인스턴스를 생성하고 이전 버전의 인스턴스로 교체하는 전략

===> 이전 버전의 인스턴스를 중지하고 새로운 버전의 인스턴스를 시작하여 변경을 불가능하게 만든다. 이는 롤백이 간단하며, 배포 전과 후의 상태가 완전히 분리되어 있다. 배포하는 시간동안 4개의 EC2가 가동하고 정상으로 배포가 되면 2대가 종료된다. 에러가 있을 경우 배포하던 새로운 EC2를 제거하면 되기 때문에 자원 소요가 적다. 

1. 오토 스케일링(Auto Scaling)

: 컴퓨터 시스템이나 애플리케이션의 작업 부하에 따라 자동으로 자원을 확장 또는 축소하는 기술

로 클라우드 컴퓨팅 환경에서 측히 유용하며, 시스템의 성능을 최적화하고 비용을 절감하는 데 도움이 된다.

▷ 서비스를 사용하면 사용자가 수동으로 인프라를 관리하지 않고도 시스템 성능을 최적화하고 효율적으로 운영 가능하다

Aws auto scaling은 주로 EC2 인스턴스의 오토 스케일링 그룹을 통해 구현된다.

2. 로드 밸랜서(Load Balancer) 

: 네트워크 트래픽이나 작업 부하를 여러 서버로 분산시켜 주는 장치 또는 서비스이다. 여러 서버 간에 균형을 유지하고, 단일 서버에 가해지는 트래픽 부하를 분산하여 성능을 향상시키고 가용성을 향상시킬 수 있다. (OSI 7계층:응용계층)

로드 밸런서의 주요 기능 및 특징
1. 부하 분해 : 로드 밸런서는 여러 서버에 대한 트래픽을 균등하게 분산시켜 줌으로써 각 서버가 일관된 성능을 유지할 수 있도록 한다.
2. 가용성 및 신뢰성 향상 : 여러 서버로 트래픽을 분산하기 때문에 특정 서버의 장애나 다운타임에도 시스템이 계속해서 동작할 수 있다.
3. 확장성 : 새로운 서버가 추가되거나 기존 서버가 제거될 때 로드 밸런서는 자동으로 이에 대응하여 부하 분배를 조절한다.
4. 세션 관리 : 일부 로드 밸런서는 클라이언트의 세션 정보를 유지하고 특정 서버에 고정시켜 세션 일관성을 유지할 수 있다.
5. SSL 오프로딩 : SSL 암호화 및 복호화 작업을 대신 수행하여 백엔드 서버에서의 부하를 감소시킬 숭 ㅣㅆ다. 

1. 엘라스틱 빈스톡을 생성하면서 오토 스케일링 그룹 생성

2. 환경 유형을 밸런싱된 로드로 설정하고 인스턴스는 2~4로 설정한다. 이는 평소에는 인스턴스 2개로 운영하다가 서버가 바빠지면 인스턴스를 4개로 늘려준다. 그리고 다시 한가해지면 원래 2개의 상태로 변환하고 생성된 2개는 제거한다.

==> EC2가 두 개면 클라이언트는 어느 EC2로 접근해야 할 지 모른다. 그래서 클라이언트는 로드밸런서로 접근하고 로드밸런서는 서버가 한가한 쪽으로 클라이언트를 보낸다. 이 때 둘 다 너무 바쁠 경우 오토 스케일링을 통해 EC2가 더 추가된다.

3. 네트워크 로드밸런서

: OSI 4계층인 전송계층에서 작동하는 로드밸런서이고, TCP/UDP 트래픽을 분산시키는 역할이다. 클라이언트 요청을 여러 대상으로 분산시키고, 효율적인 네트워크 트래픽 관리를 할 수 있다. 

- 로드밸런서로만 연결할 경우

: ALB는 IP 주소가 주기적으로 변동되기 때문에 개발자가 컨트롤할 수 없다. 로드밸런서는 DNS가 제공되기 때문에 이 DNS로 접근이 가능하지만 여러 문제가 발생할 수 있다. 

 1. 고정 IP 주소의 부재 : DNS는 동적으로 IP주소를 반환할 수 있기 때문에 로드 밸런서의 IP 주소가 동적으로 변경될 수 있다. 이 경우 클라이언트는 항상 동일한 IP주소로 연결하지 못한다.
2. DNS 캐싱 및 TTL 문제 : 클라이언트에서 DNS 응답이 캐시되면 TTL이 만료되기 전까지의 새로운 IP 주소를 알지 못한다. 
3. 로드 밸런서 장애 대응 : 직접 DNS로 연결하는 경우 로드 밸런서의 장애에 대응하기 어려울 수 있다. 만약 로드 밸런서가 다운되면 DNS로 인해 트래픽이 분산되지 않으며, 서비스 가용성에 영향을 미칠 수 있다.
4. 보안 측면 고려 : 직접 DNS로 연결할 경우, 로드 밸런서의 IP주소가 노출될 수 있따. 

- 네트워크 로드밸런스 추가할 경우

위의 문제점을 보완하기 위해 네트워크 로드밸런서를 사용한다. 네트워크 로드밸런서는 고정 IP를 사용할 수 있기 때문에 위의 IP 주소의 부재를 해결할 수 있다.

1. 고성능 및 저렴한 비용 : 빠른 속도와 낮은 지연 시간을 제공하면서도 비용 효율적으로 동작한다.
2. 4계층 로드 밸런싱 : OSI모델의 4계층에서 동작하기 때문에, TCP 및 UDP 트래픽을 처리할 수 있다.
3. 고정IP주소 : Elastic IP 주소를 제공하여 고정 IP주소를 사용할 수 있다. 
4. SSL 트래픽 지원
5. 등록된 대상의 상태 확인 : 등록된 인스턴스 또는 IP주소의 상태를 정기적으로 확인하여 정상적으로 서비스할 수 있는 대상으로만 트래픽을 전달한다.
6. 간단한 설정 및 관리 : 단순한 구성이 가능하다.

AWS 버전4으로 배포 원리

1. 엘라스틱 빈스톡에서 애플리케이션 생성하기

- 플랫폼 지정 등 필요한 것 선택

- 여기서 환경 변수에서 RDS에 대해 설정(hostname, dbname, port, username, password)

- 애플리케이션이 만들어지면 ec2에 인스턴스가 생성됨.

- 생성된 인스턴스의 퍼블릭 IP, 프라이빗IP, VPC ip, 보안 그룹 이름, 보안 그룹 Id가 만들어짐. (따로 저장해 놓게 좋다.)

- 보안그룹에서는 기본적으로 22포트와 80포트가 설정되어 있음.

2. RDS 생성하기

- 위에서 설정된 vpc id로 설정

- 엘라스틱 빈스톡 환경변수로 설정한 username과 password로 마스터 사용 이름, 암호 저장

- 퍼블릭 액세스 (예)로 설정

: 원격으로 내 컴퓨터에서 접속을 해보기 위해 퍼블릭 액세스는 (예)로 설정

=> 외부에서 누구나 접속이 가능하기 때문에 따로 설정 필요(외부는 로컬 컴퓨터에서만 접근 가능하게)

- vpc 보안 그룹 설정

=> ec2에 있는 보안 그룹을 설정하면 ec2와 rds가 같은 보안 그룹에 있음

- ec2에서 보안그룹 편집

=> mariaDB 포트인 3306포트를 해당 보안그룹에서 접근 가능하게 설정

- 클라이언트가 ec2로 접근

- rds는 로컬 컴퓨터에서 접근 가능하며, 같은 보안그룹에 있는 ec2에서만 접근 가능(같은 보안그룹끼리 접근 가능)

[외부 접근 불가]
1. VPC : 외부 액세스 금지
2. 포트 개방
- VPC1에서만 접근 가능
- 특정 IP만 접근 가능

[K-디지털] AWS 리눅스 기반 클라우드 데브옵스 기초 실무 과정 참고하며 작성하였습니다.

IAM(Identity Access Manager) : 식별 및 접근 제어로, 클라우드 서비스에서 사용자와 리소스에 대한 보안을 관리하는 데 사용되는 중요한 개념이다.

[배포 과정]

로컬이 window os이고 aws 환경은 리눅스라면 테스트와 실행의 환경이 서로 다른 OS에서 이루어진다. 이럴 경우, 실패할 확률이 높다. 

====> 그래서, CI 서버와 AWS 서버의 환경을 동일하게 해줘 실행을 보장시켜준다. 이럴 때 자동으로 테스트하고 배포까지 이루어지는 데 이때 Access Key가 필요한다. 

====> AWS의 CI/CD 서비스를 사용할 때 IAM 역할을 생성하고 이에 대한 Access Key를 생성하여 이러한 서비스들이 AWS 리소스에 접근가능한다. 이를 통해 AWS 리소스에 대한 보안을 유지하면서도 CI/CD 서비스가 자동화된 빌드, 테스트, 배포 등을 수행할 수 있다.

[IAM 예시]

1. 상품을 판매할 수 있는 상점과 상품을 생산할 수 있는 공장 그리고 상품을 나르는 트럭이 있다. 

2. 처음에는 사장님 혼자서 3가지 일을 모두했는데 바뻐지면서 3명의 직원을 채용

3. A 직원은 상점 출입과, 상품 판매를 맡고, B 직원은 공장 출입과 상품 생산, C 직원은 트럭 운전을 맡았다.

(이때 사장님은 최고 사용자인 Root, 직원들은 사용자, 해야할 일들은 권한이다.)

4. 직원을 7명 더 채용해서 해야 할 일을 다시 분류해야 한다.

5. 일단 권한들을 해야 할 일에 맞춰 분류한다.

(상점출입, 상품판매를 상품 정책 , 공장출입, 상품 생산은 공장 정책, 트럭 운전은 트럭 관리로 분류)

6. 사용자들을 각각의 정책에 맞는 따른 그룹을 생성한다.

(A~C는 상품 관리, D~F는 공장관리, G~J는 트럭관리)

7. 트럭은 상점과 공장을 출입해야 한다.

(트럭은 계속 출입하는 게 아니고 필요할 때 출입되기 때문에 역할로 분류)

역할은 사용자에게 주는 것이 아니고,  서비스에게 주는 것
===> 따라서, 역할을 정책에 따로 출입 정책하고 공장 출입, 상품으로 분류하면 그룹에서 출입 관리가 된다. 이는 그룹은 사용자들의 모임이기 때문에 될 수 없다.


===> 사용자 : 직원 
===> 정책 : 권한의 모임
===> 그룹 : 사용자의 모임
===> 역할 : 서비스

1. 사용자 관리 : IAM을 사용하여 AWS에 로그인하고 서비스 및 리소스에 대한 액세스 권한을 부여하거나 제한할 수 있는 사용자를 생성하고 관리한다.

2. 그룹 및 역할: 사용자를 그룹으로 구성하고, 각 그룹에 일괄적으로 권한을 할당하거나 제거할 수 있다. 역할은 일시적으로 필요한 권한을 부여하기 위해 사용된다.

3. 권한 관리: IAM을 사용하여 특정 서비스 또는 리소스에 대한 액세스 권한을 관리한다. 이를 통해 최소한의 권한 원칙을 준수하여 보안을 강화할 수 있다.

4. 인증 및 권한 부여 : AWS 리소스에 대한 액세스를 위해 사용자의 인증 및 권한 부여를 담당한다. 이를 통해 리소스에 대한 안전한 액세스를 제공한다.

[K-디지털] AWS 리눅스 기반 클라우드 데브옵스 기초 실무 과정 참고하며 작성하였습니다.

- CI/CD : 지속적 통합(Continuous Integration)과 지속적 배포(Continuous Deployment)를 나타낸다.

- CI(지속적 통합)
* 여러 개발자가 소스 코드를 공유 리포지토리에 통합할 때마다 자동으로 코드를 빌드하고 테스트하는 과정
* 이를 통해 버그를 빨리 찾아내고 코드 충돌을 방지하여 소프트웨어 품질을 향상시킨다.

- CD(지속적 배포)
* CI 이후, 테스트 및 빌드가 완료된 코드가 자동으로 프로덕션 환경에 배포되는 것을 의미한다.
* 이를 통해 변경 사항을 빠르게 사용자에게 제공하여 소프트웨어 업데이트를 지속적으로 이루어질 수 있다.

- 소프트웨어 개발과 배포의 과정을 자동화하여 품질을 향상시키고 릴리즈 주기를 단축시키는 것
예를 들어, Jenkins, GitLab CI/CD, Travis CI 등이 CI/CD 파이프라인을 구축하는 데 사용될 수 있다.

- 개발자가 코드를 커밋하면 CI 파이프라인이 자동으로 작동하여 빌드하고 테스트한다. 성공적으로 통과하면 CD 파이프라인이 실행되어 자동으로 배포할 수 있다. 이는 빠르고 안정적인 개발과 배포를 가능하게 한다.

---공통---

1. 다른 로컬 컴퓨터 두 대가 깃허브에 올려 blog를 통합한다.

2. 통합된 blog가 수정하고, 개발하고 등을 통해 최초 최종 blog가 만들어졌다. (blog1.0 버전)

3. 서버에서는 깃허브의 코드를 다운 받는다.

4. Junit를 통해 단위, 통합 테스트를 한다.

5. 빌드한다.

6. AWS 서버에 jar파일이 배포된다.

----------

여러 방법이 있는데 2가지만 설명하려고 한다.

하나는 폴링 기법이고 다른 하나는 WebHook이다.

폴링 기법 - Travis

이때, 폴링 기법을 통해 서버는 다운받고, 테스트하고 빌드하는 3가지 과정을 진행하고 aws에 push한다.

=> 폴링 기법은 깃허브에 10초에 한 번씩 요청을 한다. 새로운 코드가 생겼는지, 변경되었는지 확인하여 변경사항을 감지되면 서버에서 3가지 과정을 실행하여 aws에 전달한다.

폴링(Polling) : 주기적으로 상태나 정보를 확인하는 방법이다. 주기적으로 데이터를 확인하여 변경 사항이 있는지 여부를 확인한다. 

단점 ::
지속적인 요청이 발생하므로 리소스의 낭비가 발생할 수 있다. 데이터가 변경되지 않을 때에도 주기적인 확인을 계속하기 때문이다.

WebHook 기법

Git의 설정에 들어가서 webhook를 설정한다. 이렇게 하면 깃허브에 새로운 코드가 push되면 서버가 자동으로 hook를 날려준다. 

WebHook : 웹 애플리케이션이나 서비스에서 이벤트 발생 시 다른 애플리케이션으로 자동 알림을 보내느 방법이다. 주로 서로 다른 서비스나 애플리케이션 간에 통신하고 상호작용하는 데 사용된다.

==> GitHub에서 코드가 업데이트되면 특정 URL로 WebHook을 보내어 해당 코드 변경 사항을 다른 서비스(CI/CD)에 알리고 자동으로 테스트 및 배포를 실행할 수 있다.

그 밖에 GitHub Actions 등이 있다.

- GitHub Actions은 GitHub에서 제공하는 CI/CD 서비스이다. 이 서비스를 사용하면 코드 저장소에서 이벤트가 발생할 때 자동으로 특정 작업을 수행할 수 있다. 

- GitHub Actions의 핵심 개념은 '워크플로우'이다. 이를 통해 사용자가 저장소에서 발생하는 여러 이벤트(push, pull, request, issus 생성 등)에 반응하여 특정 작업을 자동화할 수 있다. 

- 소프트웨어 개발 배포 및 프로세스를 자동화하여 소프트웨어의 품질을 유지하고 릴리스 주기를 단축할 수 있다.

- 다양한 프로그래밍 언너와 프레임워크를 지원하며, 다른 서비스 및 도구와의 통합을 쉽게 구현할 수 있다.

------------먼저, 하기 전에 source 명령어에 대해 이해--------------

ls -al를 통해 .bashrc를 찾기

.bashrc 파일 : 리눅스 또는 macOS 등에서 터미널을 시작할 때마다 실행되는 스크립트 파일

                       환경변수 같은 걸 저장하는 걸정 파일, 재부팅될 때 적용됨

(1) vi ./.bashrc를 통해 export LOVE="I love you" 변수를 추가함.

(2) echo에서 위에서 저장한 LOVE라는 변수를 호출했는데 빈칸이 출력됨.

(3) source ./.bashrc 명령어를 사용해서 강제로 적용

source 명령어 : 특정 파일 안에 있는 명령어를 현재 셀 세션으로 실행하는 데 사용됨. '.bashrc' 이나 '.bash_profile'과 같은 환경 설정 파일을 수정한 후에 변경된 설정을 즉시 적용하기 위해 사용됨.

ec2 서버 배포 과정

1. 인스턴스 생성

2. 8080번 포트 오픈 권한 부여

보안그룹에서 인바운드 규칙 편집을 통해 8080 포트 범위를 누구나(0.0.0.0/0) 접근할 수 있게 변경.

3. vi var.sh 스크립트 작성

pgrep -f *.jar : 바로 해당 파일의 jar에 PID 출력

4. vi check-and-restart.sh 스크립트 작성

사용할 변수들을 정한 스크립트를 check-and-restart.sh에서 source를 통해 실행 시킴.

5. vi deploy.sh 스크립트 작성(배포 스크립트 작성)

1. env variable 환경 설정

- source 명령어를 사용하여 var.sh에서 작성한 스크립트를 실행시킴

2. clone delete 

- touch crontab_delete : crontab_delete 이라는 빈 파일을 생성하라는 명령

- crontab crontab_delete : crontab_delete 파일에 있는 cron 작업을 현재 사용자의 cron 작업으로 로드하라는 명령어

(cron : 주기적 실행)

- rm crontab_delete : 생성하나 crontab_delete 삭제. crontab에 crontab_delete에 작성한 내용을 옮겼기 때문에 삭제

3. server checking

- if [ -n "$PROJECT_PID" ]; then : PID가 0이 아니라면 kill -9 해서 PID를 강제 삭제한다.

- else : PID가 0이라면 즉 처음 배포하는 거라면

- sudo apt-get -y update 1>/dev/null : apt를 갱신하고 갱신하는 내용은 출력하지 않는다.

- sudo apt-get -y install openjdk-11-jdk 1>/dev/null : jdk를 설치하하고 그 내용은 출력하지 않는다.

- sudo timedatectl set-timezone Asia/Seoul : Asia/Seoul로 시간대로 변경

(timedatectl : 시스템의 시간 및 날짜 설정을 관리하는 명령어)

4. project folder delete

- rm -rf ${HOME}/${PROJECT_NAME} : 프로젝트 폴더를 영구적으로 삭제 (-rf를 사용할 때는 조심해야 함)

5. git clone

- sleep 3s : 3초 쉰다. (이유 : 깃 clone이 비동기 또는 동기식 둘 중 하나인데 만약 비동기식이라면 순서가 없기 때문에 꼬임이 발생할 수 있다.)

6. gradlew +x 

- 빌드할 때 실행할 수 있는 권한을 부여한다. 

7. build

8. start jar

- nohub java -jar -Dspring.profiles.active=prod ${JAR_PATH} 1>${HOME}/log.out 2>${HOME}/err.out &

: 표준 출력(1)은 log.out에 에러 출력(2)은 err.out에 출력

nohub : 리눅스에서 프로세스를 실행한 터미널의 세션 연결이 끊어지더라도 지속적으로 동작할 수 있게 해주는ㄴ 명령어
====> 포그라운드로 실행할 때는 nohub 명령어가 적용되지 않아 터미널 종료 시에 함께 종료됨. 그래서 백그라운(&)드로 실행해야 함. 
====> nohub은 자동으로 로그를 남김

*** 배포를 위해서 작성했던 모든 명령어들은 스크립트에 작성해서 자동화할 것이다. 그때 실행이 잘되지 않으면 err.out에서 확인하고 잘되면 log.out에서 확인할 수 있게 하기 위해 분리한 것이다.

9. cron registration

- touch crontab_new : crontab_new 파일 생성

- echo "* * * * * ${HOME}/check-and-restart.sh" 1>>crontab_new : 매 분마다 check_and_restart.sh 파일 실행해서 crontab_new에 추가

- crontab crontab_new : crontab에 crontab_new에 작성한 내용 반영

- rm crontab_new : 파일 삭제

=====> ./deploy.sh 하면 스크립트 실행된다. 

====> 이런 식으로 파일 생성됨.

[K-디지털] AWS 리눅스 기반 클라우드 데브옵스 기초 실무 과정 참고하며 작성하였습니다.

1. CPU(연산장치)는 RAM(휘발성 저장장치)와 대화를 함.

2. RAM은 1기가 바이트(문자 10억 개 저장 가능)의 메모리를 가지고 있음.

3. 30기가 바이트의 메모리를 가진 HDD 또는 SSD에서 Tomcat8, 카톡, 유튜브 등의 프로그램이 있을 때

4. 내가 원하는 실행하는 싶은 것은 Tomcat8임

5. Tomcat8를 실행할 때 필요한 부분만 RAM에게 로드. 이때의 Tomcat8은 프로세스

6. CPU에게 전달함.

프로세스 

CPU 1개는 일하는 노동자 1명과도 같음(프로세스 1개)

cpu에서 Tomcat를 실행하게 되면 다음으로 실행하고 싶은 카카오톡은 실행할 수 없다.

===> 그래서 Thread를 사용(Thread를 사용하면 tomcat과 카카오톡를 동시에 사용할 수 있다.

===> tomcat을 어느 정도 실행한 후 잠시 카카오톡을 하러 갔다가 다시 tomat으로 올 때 어디서부터 실행해야 하는지 기억ㅎ야 함.

- Thread(실, 수명): 프로세스에서 실행되는 가장 작은 단위

- Context(문맥) : 해당 스레드의 실행 상태를 나타내는 정보 집합 (전, 후 사정)

- CPU가 Thread에 따라 왔다갔다 하며 프로세스를 실행한다. 이때 0.1초 자고 실행 하는 과정 반복

>>> 문맥 전환은 다중 스레드 프로그래밍에서 동시성을 관리하고 스레드 간에 실행을 조율하는 데 중요한 역할

CPU는 A와 B를 동시에 할 수 있지만, Thread가 필요하다. 타임 슬라이싱하면 왔다갔다 교환하며 실행하는데 이 과정을 Context Switching이라고 한다. 이 때 Sleep라는 것이 필요하고 Sleep를 통해 강제 종로도 가능!

리눅스 프로세스 명령어

apt 명령어를 설치하면 서비스에 등록이 된다. 서비스에 등록되면 실행파일을 직접 찾아서 실행할 필요가 없다.

sudo service tomcat8 stop : tomcat8 서비스 종료

sudo service tomcat8 start : tomcat8 서비스 시작

==> 위의 두 명령은 잘 사용되지 않음!

* service 명령어 : systemctl의 wrapper script

* systemctl : 서빗스 제어 명령어

sudo systemctl list-unit-files : 실행 중인 시스템 화면에 출력

sudo systemctl list-unit-files | grep tomcat8 : 실행 중인 tomcat8 화면에 출력

--> enable : 현재 사용가능한 상태

sudo systemctl status tomcat8 : tomcat8의 현재 상태

sudo systemctl stop tomcat8 : 실행 중인 프로세스인 tomcat8 종료

sudo systemctl start tomcat8 : tomcat8 시작

프로세스 : 서버로부터 동작 중인 것
데몬 프로세스 : while문을 돌고 있는 프로세스

* kill -l : kill 종료 옵션 보기
* kill - 9 PID : 프로세스 강제 종료
* kill pid : 프로세스를 안전하게 종료 시킨다. 
-> kill pid를 사용해서 프로세스를 종료 시키면 sudo systemctl start 명령어를 사용해서 실행시키면 안되기 때문에 sudo systemctl restart 명령어를 사용해야 한다.(systemctl 입장에서는 exit된 것이다. 안전한 종료 후 restart로만 실행된다. 왜냐하면 systemctl 입장에서는 종료가 아니고 중지된 상태이기 때문이다.) 

[K-디지털] AWS 리눅스 기반 클라우드 데브옵스 기초 실무 과정 참고하며 작성하였습니다.