API 개발을 하는데 필요한 운영관리도구들이

• git : 프로젝트 관리도구
• Docker : 배포 간소화에 많이 사용되는 가상화 도구
• Postman : API 테스팅 도구

git

• 리눅스 토발즈
• 리눅스 개발하다 깃 개발.
• 당시 유행하던 프로젝트 관리도구 SVN과 CVS를 증오하던 리누스는 Bitkeeper 소프트웨어의 정책변경과 함꼐 직접 자신이 필요로 하는 기능들을 포함한 git을 직접 개발.

비트키퍼에서 역공학을 해서 리눅스 개발자들이 비트키퍼가 못쓰게 되면서 깃을 만들어냄.

리누스 토발즈는 git을 만들었지 깃허브는 안 만들음.

깃허브는 깃으로 만들어진 소스들을 관리하기 위한 서버

.git이라는 레파지토리가 어떻게 작동하나.

폴더들 보여주는 gui도구에 이 폴더 하나가 실제 깃 레포지토리를 상징함.

깃허브에도 저장이 되어있음. 사실상 .git 내부에 있는 파일들이 변경을 확인하고 git이 만들어둔 게 .git이다.

SVN 과 Git의 차이.

• 분산이 되느냐 안되느냐의 차이
  • 분산 처리의 이야기가 아닌 소스코드의 관리 관점
• SVN
  • 중앙 집중식 버전 관리
  • 수정할 내용을 사용자가 받아와서 수정
  • 후 서버에 통합
• Git
  • Local에서만 작업도 가능
  • Local에 작업된 것들을 통합하는 서버에서 관리 가능
  • 서버가 날아가도 개별작업 가능

SVN은 중앙에서 관리하고 일부분 가져와서 관리한다. 깃은 서버에 존재하는 모든 소스를 로컬에 가져와서 그거 변경사항을 수정하고 적용을 한다.

.git이 깃이 확인하는 모든것.

이 디렉토리를 지우면 깃 레포지토리로서 작동을 하지 않는다.

Git은 일반적으로 다 커밋으로 작동이한다. 16진수로 작성되서 f보다 더 위의 문자로 이뤄지지 않는다. 즉 위의 commit은 그냥 예시.

모든 깃의 다른 기능들도 이 커밋을 조작하는 방식으로 이뤄지게 됨.

튜링?

컴퓨터의 시초를 만들어내신 분. 그 분이 오토마타는 기계라는 말인데 튜링 머신이라는 일종의 오토마타. 굉장히 크나큰 업적들 많이 만들어둠.

git에 head가 존재하는데 작동하는 방식이 유사하다고 한다.

Git init

Git 레포지토리에서 가장 기본적인 거.

master브랜치를 기본 브랜치로 하지 말아라..?

깃허브에서 시작하는게 아니라 로컬에서 시작하는 거.

엄밀히 말하면 문자열하나하나가 나열된 바이트의 연속임.

워드로 작성된 문서들도 깃이 관리도 되지만 권장은 안됨.

소스들은 순수한 문자들만 있으니까 그걸 관리하기 위함이였다.

자신의 폴더에만 생성된 상태(깃이)

Git remote add origin

• git remote add origin url

어떤 원격 저장소에다 내 소스를 저장할 지.

동료와 협업하기 위해서 사용하는 거.

깃 자체는 협업을 위한 도구. 정확히는 원격 저장소를 지정을 하기 위함.

url = uniform resource location url에 위치에 http만 사용할 필요는 없다. origin을 저장함으로서 이 레포지토리에 전달할거라는 걸 넣어논거라 보면 된다.

origin도 있고 원격 레포지토리를 볼 수 있다.

Git 협업시 무조건 처음 할 것.

• git fetch: 원격 저장소의 commit 이력들을 가져오는 것.

• git pull : 원격 저장소의 이력들을 적용하는 것.

• fetch 와 pull의 차이?

원격에서 수정한 내용들이 fetch는 다른사람이 작업한 걸 가져오는 거 f

둘다 깃이 인지하는 상태는 똑같은데

origin에 있는 상태랑 동일한데 git fetch와 git pull의 상태가 동일하지 않다.

fetch는 이력 자체만 가져오고 git pull은 양 쪽에서 변경된 상태에서 변경되었을 때 뭘 먼저 해야하는 지 모르므로 충돌 나거나 거절 할 수 있다.

일반적으로는 pull 많이 쓴다.

하루 일과 중 제일 먼저 해야할 것.

git clone : 원격 저장소에 참여하여 개발.

원격 저장소에 요청을 보냄. 원격저장소에 있는 소스를 가지고 온다. 근데 권한에 대해 생각해 보면 pull, clone 이든 작동 안하게 할 방법도 있다.

clone한 것도 push 가 가능하다. git 을 클론할 조건과 pull할수 있는 조건이 똑같다.

그 원격 저장소에서 가지고 있는 사용자의 권한을 확인 후 pull이든 clone이든 가능하게 하는 것이므로.

git - status, add, commit, push

깃은 커밋 단위로 관리한다. 이제 오리진에 있던 메인이 앞서가게 된다.

git이 중요하지만 어떤 행동을 하는지에 대해 알고 있어야 문제 일어났을 때 해결하기 쉬워진다.

git에 저장되는 건 모든 것이 커밋 단위이다.

git - checkout, reset

add는 안 된 상태에서 원래 작업 진행 이전상태로 돌아가기 위한 체크아웃으로 명령어 사용. index에서 한개 수정했다 뜬다. 내가 알고 있는 기준을 상태로 되돌려 놨다.

체크아웃은 작업한 이력을 원상태로 돌리기 위해서 쓴다.

이거 쓸 일이 많지는 않음.

롤백을 쓰면 사실상 체크아웃과 똑같은 명령어. 현재 레포지토리 기준으로 동일한 걸 비교한다.

git diff 를통해 어떤게 변했는지 볼 수 있다.

변경사항을 한번에 되돌리기 위해 체크아웃을 쓴다.

리셋은 add 한 뒤에 생각할 수 있다.

이 이력을 커밋으로 저장하기 위해서 add를 썼다 치면 head는 작성해야할 내용이라고 생각한다.

체크아웃 넣어도 변경사항 존재하지 않음.

이력으로 관리 되어야 하는 항목이라 하낟.

HEAD가 얘를 알고 있기 떄문에 모르는 상태로 돌려줄 떄 reset을 쓴다.

git으로 실수 많이하는 거 같으면 cli로 연습해라.

reset으로 좀더 커밋 이력 자체를 뒤로 돌릴 수 있다.

git reset HEAD~1

원래 존재하는 커밋 까지 돌릴 수 있는게 git reset.

이건 원격저장소가 아니라 로컬 저장소 기준으로 체크아웃 작동함.

그럼 잘못 커밋 잘못 했을 때는 git pull 해서 reset해서 커밋 이력 되돌리고 다시 풀하면 되나?

soft: 커밋 자체는 지워지지만 변경 상태로는 유지함. 작성할 상태로 돌아감. 커밋만 되돌리고 작업 상태는 그대로 인것.

git mixed는 작업이 있는데 얘를 이력으로 기록할 상태는 아님.

mixed인 이유가 soft는 변경사항이라는 걸 기억함. mixed는 변경사항이라는 걸 잊어버림.

git hard : 아예 변경사항 지워진다.

리셋 하고오기에는 변경사항을 다른사람이

테이블이

머신에 헤드가 현재 상태 확인하고 받은 명령어를 기록하고 좌측이나 우측 가거나 이런식으로 행동.

튜링 머신이 상태를 기준으로 판단하고

튜링머신으로 파악 못하는 건 상태관리로 파악 못한다.

뭔가 상태에 따라 변하는 무언가를 만들 떄엔 튜링머신의 복잡도가 제일 높음.

상하좌우로 움직이게 한다던지 확장하게 하려는 시도가 있었는데 튜링머신으로 제어가 되는게 증명이 됨.

git - branching strategy

카나리 방식 카나리, 개별 브랜치 존재

dev이 개발자가 작업하는 브랜치로 카나리는 릴리스 이전의 대타 브랜치로 상용 브랜치가 마스터 브랜치.

크롬 같은 경우에는 크롬 카나리 버전이 따로 존재.

카나리 테스팅을 하기 위해 요청이 4번 보내면 카나리로 1번 보내는 건데 이걸 마스터로 한번 보낸다 이런 식이 있는데 이런게 있다.

카나리 브랜치에서 복사본을 따오고 그걸 개별 브랜치에서 한다음에 카나리 브랜치로 다시 푸시 및, 머지를 보낸다.

그걸 하길 위해 branch 와 canary를 사용한다.

checkout은 직역하면 확인해보자는 뜻.

생성된 브랜치를 확인하기 위해 명령어로 사용.

체크 아웃을 그런식으로도 사용 될 수 있다.

-b 옵션 주면 새로운 브랜치 생성하고 체크아웃하는거.

새로운 기능 개발하기 위해 브랜치 따는 거. 그럼 카나리나 다른 브랜치로 체크아웃하거나 -b옵션 주고 체크아웃 하거나.

새로운 브랜치 생성되었을떄 체크아웃해서 가져오는게 그냥 체크아웃 명령어.

새로운 브랜치를 만들거나 제거할 때 옵션을 조합해서 사용한다.

브랜치와 체크아웃을 통해서 브랜치 관리하는 전략을 만들어간다.

중요한 건 브랜치 전략을 가지고 간다.

브랜치가 서로 다른사람이 하는 일을 유연하게 관리한다.

깃과 깃허브는 다르다!

깃허브에 새로 브랜치 안 만들고 로컬에서 브랜치 만들었을때 오리진에 브랜치 만들기 위해 push 에 옵션이 붙게 되는데 그게

git push –set-upstream origin 이다.

얘를 들면 test_b라는 상태는 기섷브에 없는데 여기서 push를 바로 보내면 upstream하라고 요청한다.

origin에 내가 넣어주고 싶은걸 넣어준다.

git merge

현재 브랜치에 브랜치 네임을 합친다.

• ff(fast-forward): 현재 브랜치 위에 합치려는 브랜치의 commit을 얹는다.

• no-ff(no fast-forward): 두 브랜치를 합치는 과정을 커밋으로 기록한다.

둘다 결과물은 똑같음. ff는 잘 어우러지게. 시간순으로 쌓는거. a가 먼저 변경되었으면 기본상태에서 a넣고 그다음 b넣고 그에따른 결과가 머지의 완성.

상대방 브랜치에 있던걸 빨리 감기 한 것.

noff는 명백한 서로 다른 상태를 하나의 커밋 상태로 합침.

커밋은 작업 이력을 나타내니까 새로운 커밋으로 나타냄.

pr할때 내부적으로 돌아가는거.

conflict는 머지에서 일어나는 문제.

머지는 서로 다른 이력을 합치는 거.

서로 맡은 바가 달라서 파일에서 다른부분 만지니까 합쳐도

같은 파일의 같은 부분 변경할 떄 컨플릭트가 발생한다.

얘 둘을 머지 하려 할때 다른 브랜치가 동시에 변경 날 때 어떤걸 해야할지

그래서 수동으로 컨플릭트를 해소해야한다.

상대방의 커밋을 풀을 받을때 문제 받을 떄가 많은데 로그 메시지로도 문제 발생 할 수 있다.

conflict가 문제 일어나는거 알면 해결하기 쉬움.

사진은 머지가 안된 경로가 존재한다고 뜬다.

적용이 되어야 되는 커밋들이 커밋 안된 상태로 남아있을 수 있다.

사실상 여기서 ff가 작동 불가(머지 이력이 달라서.

git의 기본은 모든것이 커밋단위로 일어난다. 그럼 모든 문제가 커밋 단위로 일어나게 된다.

그외에도 많은 기능이 있는데 어느 수준이 되기 전까지는 더 많이 알아야 한다고는 생각하지는 않는다.

작업을 충돌 없이 잘 하기 위해서는 여기까지만 알아도 된다.

https://dev.to/lydiahallie/cs-visualized-useful-git-commands-37p1

도커

• 현재 가장 뜨거운 가상화 도구

사실상 거의 대부분 이걸 사용한다.

하이퍼 바이저라는 걸 가상화를 사용했는데 (도커 사용 방식은 왼쪽 , 원래 가상화는 오른쪽)

도커가 굉장히 편리한 도구로만 알면 된다.

• 도커는 상용 환경에서 사용되는 프로그램의 설치
• 자신 개발한 서비스의 배포 관리

등의 용도로 사용된다.

도커를 통해서 배포가 되면 서버로 올리는데 jdk가 필요하진 않아짐.

컨테이너에 올라가면 안에서 다 조절이 된다.

내 컴퓨터에도 도커 엔진이 있으면 다른 소프트웨어들이 내 컴퓨터에서 정상 작동하는 데 문제가 없다.

자바를 서버에서 실행한다 생각했을 때 target java version에 맞는 jre가 필요한데

도커를 설치해뒀으면 된다.

jvm 설치하면 자바만 돌릴수 있는데 도커 설치하면 jvm 이외에도 다 돌릴 수 있다.

images - ps -

어떤 컨테이너가 돌고 있다 어떤 이미지가 돌고 있다.

ps를 통해 컨테이너 확인.

• 도커가 데몬과 비슷하다고 보면된다.

• 개발을 해놓은 프로그램을 돌릴지 어떤 환경으로 갖춰져 있는게 도커파일. 얘를 명령어를 통해 빌드해서 나온 결과 물이 이미지.

• 이 이미지에 필요한 환경변수, 실제로 작동하는 어플리케이션을 컨테이너라고 한다.

도커로 배포하고 싶으면 도커파일로 만들고 이미지로 만들면 그걸 기반으로 컨테이너를 만든다.

환경설정 미리 해줘야 되는게 몇 있는데

from이 도커파일이 시작할 이미지를 기준으로 진행한다. 여기서 내 작업디렉토리를 현재디렉토리로 설정하고 이미지 내부에 있는 모든 디렉토리에 복사하고 실행 명령은 python3, hello.py라고 한다.

이미지나 실행된 컨테이너 내부에도 디렉터리 구조가 존재한다.

내가 하고자 하는 지정해주기 위한 명령어 두줄이 workdir. copy.. 이 두줄이라 보면 된다.

내가 만든 애플리 실행하기 위해서 그 밑의 cmd를 실행하면 된다.

그걸 build라는 명령어를 통해서 그 아래가 진행이 된다.

python이 실제이미지고 3.7은 버전의미

워크디렉토리를 현재디렉토리로 설정 현재 디렉토리를 파이썬 이미지 디렉토리에 넣는다 커맨드는 맨 아래처럼 실행한다.

파이썬 3.37 버전 제공하기 위해 이런 이미지

그럼 이 이미지는 파이썬 애플리케이션 실행하기위한 도커파일을 만든다. 그럼 이 도커파일로

받으면 파이썬이 안 깔려있어도 도커가 정상적으로 되어있으면 이 컨테이너를 만들기 위한 파이썬이 정상적으로 만들어져 있어서 정상적으로 돌아간다.

서버에 영향을 많이 안 받는다.

run이라는 명령어 통해서 결과물을 볼 수 있다.

실제로는 웹 애플리케이션은 포트바인딩을 통해 지속적으로 떠 있는 상태로 될 수 있다.

사용하는 걸 좀 더 보면 된다.

이름은 저장소 이름 태그는 cli에 나옴. 환경변수 = OS에 기록되어있는 변수들. 그런거들 설정하기 위한 옵션이 e옵션

실제로 도커파일 통해서 스프링부트 애플리케이션 할텐데 미리 있다는 걸 알아둬야한다.

관리의 목적에선 name이 상당히 중요하다.

윈도우 리눅스 도커 따로 나눈 이유가? - 환경이 다 달라서 그런가.

그럼 이 도커파일을 aws이런 곳에 올리는 건가?

컨테이너가 환경인건가?

이미지 파일에 컨테이너 까지 올라가나?

이미지 자체로서는 어떤 식으로 실행 되어야 되는 지 에 대한 설명서 컨테이너는 설명서 대로 실행이 된 프로세스가 됨.

파이썬 이미지를 받아왔다고 파이썬을 이미지 자체로는 실행을 해야되는거 이 이미가 정상 실행되었을 때 그 컨테이너 안에서는 이미지를 실행해야 도커가 컨테이너화 하기위한 거.

실제 애플리 케이션이 실행되는 도커.

이미지를 가지고 컨테이너로 실행

아마존에서 이미지를 기존으로

이미지 - 붕어빵 틀 그럼 이미지 파일을 ec2에 배포하는 거?

결론으로 도커파일로

차도 휘발유, 경유가 있는데 이미지는 차가 어떤차인지 알려주면 컨테이너는 어떤 기름 넣을지

이미지 제공받으면 컨테이너로 돌리니까 aws도 컨테이너를 제공 받지는 않아도 된다.

https://velog.io/@devmin/Docker-deployment

Docker Hub

도커 레지스트리를 크게 만든거

깃은 리누스가 오픈소스로 만들었는데 도커하브는 자신이 필요로 하는 이미지 찾아서 쓰면 된다.

mysql 을 공식 이미지 이런게 뜬다. 어떤 버전 지원하고 실행 방법이 나온다.

도커로 mysql을 설치하라 하면 도커 이미지 받아다가 쓰면된다. 도커런 실행하면 됨.

도커 런 실행할 때 mysql을 설치하기 위한 이미지 방식 했을 때 내 로컬 이미지 관리에 없다 하면

이런식으로 나온다.

근데 없어도 이미지 를 가져와서 실행을 한다. -e 옵션이 여기서 바로 사용되었네. 설정하는데 e옵션 많이 쓴다 했는데 바로 썼네.

도커 관련 명령어는 나열 할 수 없을 만큼 많다.

도커허브라는 사이트에 자기 이미지를 팔기 위해 명령어가 잘 되어있다.

포스트맨

post맨은 실행환경 설정한다.

api 개발하면서 설정.

로컬 부분에 http, ip, cloud, gate, auth 등 있는데 이걸 변수들이 존재하는데 값들이 조금 씩 다름.

그 요청들을 보면

개발환경에서나 로컬환경에서 테스트 할떄 ip가 로컬호스트 되고 바꿔주면 ip가 실제로 가야되는 환경으로 바뀐다.

environment 에서 다양하게 설정 가능하다도 알아두면 좋다.

openApi가 어떤식으로 작동하는지에 대한 설명.

post맨에대한 거도 기능 조금씩 제공한다.

environment잘 쓰면 유용한다.

API테스팅 http Client SoftWare

개발도 수능 언어마냥 문단 나누고 잘 이해하고 개념 잘 이해하는 게 좋다.

다음시간 전에 dockerhub. mysql 컨테이너화 해서 실행을 한다.

mysql workbench나 데이터 그립 많이 쓰신다고 한다.

쿼리 만드는 데 편리하기 위해 쓰는거니까.

mysql을 도커로 설치하는걸 해보자.

윈도우스에 mysql 받아도 되기는 한다. 가능하면 도커로해보는 걸 추천한다.

버츄얼 박스랑 도커랑 기본적으로 가상환경.

도커 컨테이너 띄우면 얘가 호스트 os 내컴퓨터 안에 격리가된 상태 이컨테이너에서 실행되도록 p옵션을 주는데 이걸 버츄에박스에서 mysql에서 받으면 버츄어박스와 mysql이 소통되는데 그 외부에 있는 os와 소통이 되는가.

.