Git?

Git은 Linux 운영 체제 커널을 만든 사람으로 유명한 Linus Torvalds가 개발하였다. 

리눅스 환경에서 버전관리를 위해 만들어진 분산 버전 관리 시스템이다.

 

버전 관리?

팀프로젝트 마지막 발표를 위한 ppt를 만든다고 가정하자.

1. 초안 PPT 작성 후 팀원들에게 보여준다. (발표.ppt)

2. 팀원의 피드백으로 수정을 한다. (발표2.ppt)

3. 다시 피드백을 받고, 수정한다. (발표3.ppt)

이러한 피드백과 수정 절차가 계속 반복되고 나면 어느새 발표n.ppt가 되어 있다.

이렇게 계속되서 새로운 버전의 ppt 파일이 쌓이다 보면 어떤 버전에서 어느 부분이 수정되고, 삭제되었는지도 현재 버전이 몇 버전인지도 헷갈리게 된다.

이러한 버전 관리를 수동이 아닌 자동으로 관리해주는 것이 버전 관리 시스템이다.

버전 관리 시스템에는 여러가지가 있지만 그중 대표적으로 가장 많이 사용되는 것이 Git이다.

 

버전 관리 시스템의 목적

1. version

2. backup

3. cooperation

 

Git 이해하기

Git의 가장 기본적으로 많이 사용하는 명령어는 아래 5가지가 있다.

1. commit - 변경 사항을 저장

2. push - 로컬에 저장해 놓은 변경 사항들을 원격저장소에 저장

3. pull - 원견 저장소에 저장된 데이터를 로컬로 받아옴

4. branch - 새로운 브랜치 생성

5. merge - 브랜치와 브랜치 병합(결합)

 

1. Commit 

Commit은 변경된 내용을 저장하는 것이다.

Commit을 하게 되면 아래 사진과 같이 누가, 언제, 어떤 브랜치로 커밋을 했는지 알 수 있다.

CommitID의 경우 Author + Date + Commit Message 를 하나의 문자열로 만들어 SHA-1 해시함에 돌려 만든 값의 40자를 commit id로 사용한다.

git commit -m "commit message"

 

만약 내가 test.txt 파일에 1을 입력하고 v1으로 commit을 하면 main branch로 v1이 commit 된 것을 확인할 수 있다.

그리고 로컬에서 다시 test.txt파일에 1을 지우고 2를 입력하고 v2으로 commit하면 main branch로 v2가 commit된 것을 확인할 수 있다.

 

2.  branch

branch는 보통 새로운 기능을 추가하거나 할때 사용한다. 

git branch feature/login

 

3. push

Push는 원격 저장소에 로컬에서 내가 commit한 내용들을 저장하는 것이다.

# git push {원격저장소 이름} {원격저장소에 저장할 브랜치 이름}
git push origin main

 

4. pull

Pull은 원격 저장소에서 로컬로 저장된 내용들을 받아오는 것이다.

# git pull {원격저장소 이름} {받아올 branch 이름}
git pull origin main

 

 

4.  merge

merge는 원격 저장소에서 pull 받을 때 conflict가 나거나 작업중이던 branch를 다른 branch와 합치고자 할 때 사용한다.

'git merge {target branch 이름}' 명령어를 실행하게 되면 현재 branch에 target branch가 병합되게 된다.

git merge {합칠 대상}

 

 

명령어 실습

1. test.txt 파일 생성 (내용 1)

 

2. commit message [v1]로 commit

- git init 은 해당 폴더가 git 버전 관리 대상 폴더라고 지정해주는 것

- git add -> commit 대상 파일로 지정

 

3. git show 명령어를 통해 현재 commit 현황 확인

HEAD -> main -> v1인 상태이다.

 

4. test.txt 파일 내용을 변경 후 v2로 commit

 

5. git show를 통해 현황 확인

HEAD -> main -> v2인 것을 확인

 

6. 현재 브랜치에서 새로운 브랜치 feature/login 생성

branch를 생성하고 checkout을 해줘야한다.

브랜치를 생성했다고 자동으로 해당 브랜치로 checkout되는 것이 아니다.

git branch feature/login
git checkout feature/login

 

7. login branch에서 login txt 파일 생성 후 login commit

 

8. git graph는 다음과 같아 진다.

HEAD -> feature/login -> login -> v2

main -> v2 -> v1

 

9. main으로 다시 checkout하고. [git checkout main ] v3를 commit 한다.

이렇게 되면 다시 HEAD -> main -> v3 -> v2 -> v1

feature/login -> login -> v2 가 된다.

그림으로 보면 다음과 같다.

login branch에서 login.txt 파일을 생성했기 때문에 v3에서는 login.txt 파일을 찾을 수 없는 상태가 된다.

login branch에서 작업한 내용을 모두 완료했다고 가정하여 main branch에 반영하고 싶을 때 merge를 사용한다.

 

10. login branch 작업 내용을 main branch에 merge

 

main에 feature/login을 merge하게 되면 아래와 같이 login.txt 파일을 확인할 수 있는 것을 볼 수 있다.

 

작업 내용은 다음과 같이 된다.

728x90

'DevOps\etc' 카테고리의 다른 글

[ CI/CD ] CI/CD란?  (4) 2022.11.10

1.  AWS 계정 생성

계정 만들기 준비물

  1. 해외 결제가 가능한 신용카드 혹은 체크카드
  2. 사용가능한 이메일 주소
  3. 인증가능한 휴대폰 번호

아래 링크에서 가입

 

AWS Management Console

AWS Support 플랜은 AWS로 성공하는 데 도움이 되는 다양한 도구, 프로그램 및 전문 지식에 대한 액세스의 조합을 제공합니다.

aws.amazon.com

 

2.  웹 서버 만들기

2-1. 콘솔에 VPC 검색

 

2-2.  VPC 생성

- 이름: 원하는 이름으로 설정

- IPv4 CIDR: 원하는 IP 대역 설정

 

2-3. 서브넷 생성

- VPC ID: 이전에 만든 vpc 선택

- 서브넷 이름: 원하는 이름 설정

- 가용 영역: ap-northeast-2a

- IPv4 VPC CIDR block: 자동생성

- IPv44 subnet CIDR block: 자동생성된 값에서 뒤에만 24

 

2-4.  인터넷 게이트웨이 생성

- 이름 태그: 원하는 이름 설정

 

 

2-5.  라우팅 테이블 편집

 VPC가 내가 만들었던 VPC인 라우팅 테이블을 편집해야 함.

- 아래와 같이 설정

 

 

3. EC2 생성

3-1. 콘솔에 EC2 검색

 

3-2. 보안그룹 생성

- 보안 그룹 이름, 설명 : 원하는 값 설정

- VPC: 앞에서 만든 VPC설정

 

- 인바운드 규칙

ssh 접속을 위한 22 포트 + 내 IP

http 접속을 위한 80 포트 + 내 IP

 

3-3.  인스턴스 시작

 

3-4.  인스턴스 연결

1. .aws 폴더 생성

mkdir .aws
cd .aws

 

2. 만들었던 키페어 복사

cp source.pem new.pem

 

3. pem 권한 수정

chmod 400 keypair.pem

 

4. ssh 접속

ssh -i "keypair.pem" ec2-user@43.202.33.28

 

 

 

4.  Apache Web server install

sudo yum install httpd -y

 

5. Apache Web server start

sudo service httpd start
Redirecting to /bin/systemctl start httpd.service

 

6. http://(EC2퍼블릭IP):80으로 접속

 

7.  index.html 페이지 띄우기

7-1. /var/www/html 폴더로 이동

cd /var/www/html

 

7-2.  index.html 파일 생성

sudo vi index.html

 

<!DOCTYPE HTML>
<html>
	<head></head>
    <body>
    	<h1>This is My Web Page!</h1>
    </body>
</html>

 

 

8. http://[ec2 public ip]:80 접속

728x90

Docker

Docker는 Linux의 응용 프로그램들을 프로세스 격리 기술들을 사용해 Container로 실행하고 관리하는 오픈 소스 프로젝트이다.

 

도커 컨테이너는 일종의 소프트웨어를 소프트웨어의 실행에 필요한 모든 것을 포함하는 완전한 파일 시스템 안에 감싼다.
코드, 런타임, 시스템 도구, 시스템 라이브러리 등 서버에 설치되는 무엇이든 아우른다. 
이는 실행 중인 환경에 관계 없이 언제나 동일하게 실행될 것을 보증한다.
reference : https://www.docker.com/resources/what-container/

 

개발자는 Docker를 통해서 application을 컨테이너로 패키징 할 수 있다. 

컨테이너란 application source code를 임의의 환경에서 해당 코드의 실행에 필요한 운영체제(OS), 라이브러리 및 종속 항목과 결합하는 실행 가능한 표준 컴포넌트를 의미한다. 

컨테이너는 분산형 application의 delivery를 간소화하며, 이는 기업의 클라우드 네이티브 개발 및 하이브리드 멀티클라우드 환경으로 이전하면서 점점 더 유명세를 타고있다.

 

개발자는 Docker를 사용하지 않고도 컨테이너를 구축할 수 있다. 그러나 Docker Platform을 이용하면 보다 더 쉽고, 간편하고, 안전하게 컨테이너를 빌드, 배치 및 관리할 수 있다. 

Docker는 기본적으로 개발자가 단일 API를 통한 업무 절감 자동화와 간단한 명령을 사용하여 컨테이너를 빌드, 배치, 실행, 업데이트 및 중지할 수 있도록 해주는 toolkit이다.

 

 

 


 

 

Reference

 

Docker란 무엇입니까? | AWS

Q: Docker로 어떤 작업을 할 수 있습니까? Docker를 사용하면 환경에 구애받지 않고 애플리케이션을 신속하게 배포 및 확장할 수 있으며 코드가 문제없이 실행될 것임을 확신할 수 있습니다. 이는 Doc

aws.amazon.com

 

Docker란 무엇인가?

Docker란 무엇이며 이 컨테이너 레지스트리는 클라우드에서 어떻게 사용되나요? 민첩한 운영 및 통합 컨테이너 보안을 활용하는 Docker가 클라우드 네이티브 애플리케이션을 위한 최고의 컨테이너

www.oracle.com

 

 

 

728x90

 CI/CD란?

CI(Continuous Integration)/CD(Continuous Delivery/Continuous Deployment)의 약자이다.

CI/CD는 application 개발 단계를 자동화(automation)하여 application을 보다 짧은 주기로 customer에게 제공하는 방법을 의미한다.

 

❗️CI/CD의 기본 개념은 지속적인 통합, 지속적인 서비스 제공, 지속적인 배포를 의미하며, 새로운 코드 통합으로 인해 개발 및 운영팀에 발생하는 문제 ( integration hell ) 해결하기 위한 solution 이다.

 

CI(Continuous Integration) - "빌드와 테스트 자동화"

CI(Continuous Integration) 빌드/테스트 자동화 과정이다. CI는 개발자를 위한 자동화 프로세스인 지속적인 통합을 의미한다. 

CI를 성공적으로 구현할 경우 application에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 repository에 통합되므로 여러 명의 개발자가 동시에 application 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있다.

 

CI가 나오기 이전에는 개발을 마치고 배포가 되어야만 코드에 오류가 있는지 없는지, 해당 application이 제대로 동작하는지를 검증하며, 코드 품질을 관리할 수 있었다. 그러나 CI를 적용하게 되면서 각 개발자가 서로 다른 기능을 구현하고 완성된 후 main branch와 merge하고 만약 버그가 있다면 코드를 수정하여 해결한다. 

CI를 적용하기 전에는 개발자가 직접 코드를 병합, 빌드, 테스트 과정에 많은 시간이 소요되었었으나, CI를 적용하게 되면서 개발자가 코드를 branch에 merge하기만 하면 자동으로 빌드와 테스트를 검증할 수 있어 소요 시간이 감소되었다.

 

🙂 CI 간단한 순서

1. 개발자가 구현한 코드를 기존 코드와 병합(merge)한다.

2. 병합된 코드가 올바르게 동작하고 빌드되는지 검증한다.

3. 테스트 결과 문제가 있다면 수정하고 다시 1로 돌아간다. 문제가 없다면 배포를 진행한다.

 

CD(Continuous Delivery/Deployment)

CD(Continuous Delivery/Deployment)는 지속적인 서비스 및 지속적인 배포를 의미하며, 두 용어는 상호 교환적으로 사용된다. 두가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 한다. 

 

CD는 지속적 배포로 소프트웨어가 항상 신뢰 가능한 수준에서 배포될 수 있도록 관리하자는 개념으로 지속적 제공(Continuous Delivery)로 사용되기도 한다.

 

지속적 제공(Continuous Delivery)은 CI를 통해서 새로운 소스코드의 빌드와 테스트 병합까지 성공적으로 진행이 되었다면, 빌드와 테스트를 거쳐 github와 같은 저장소(repository)에 자동으로 업로드되는 것을 의미한다.

운영팀은 이 repository에서 application을 실시간 프로덕션 환경으로 배포할 수 있다. 지속적인 제공은 최소한의 노력으로 새로운 코드를 배포하는 것을 목표로 한다.

 

지속적 배포(Continuous Deployment)는 성공적으로 병합된 내역을 저장소뿐만 아니라 사용자가 사용할 수 있는 배포환경까지 릴리즈하는 것을 의미한다. 이는 applicatin 제공 속도를 저해하는 수동 프로세스로 인한 운영팀의 프로세스 과부하 문제를 해결한다. 지속적인 배포는 파이프라인의 다음 단계를 자동화함으로써 지속적인 제공이 가진 장점을 활용한다.

 

 

 

Reference

 

CI/CD가 뭔가요? - 이론편

tecoble.techcourse.co.kr

 

CI/CD(지속적 통합/지속적 제공): 개념, 방법, 장점, 구현 과정

CI/CD는 애플리케이션의 통합 및 테스트부터 제공 및 배포까지 전체 라이프사이클에서 지속적인 자동화와 모니터링을 제공합니다. 개념, 차이점, 학습방법(인강)을 보세요.

www.redhat.com

 

728x90

'DevOps\etc' 카테고리의 다른 글

Git  (1) 2024.02.26

+ Recent posts