출근한지 2일차

오늘은 회사의 하드웨어 작동방식과 기초 이론에 대해 공부중이다.

첫 날인 어제와는 다르게 30분 일찍 출근했다.
역시 출근길은 출근길인갑다.
어제는 8시에 출발해서 9시 50분에 도착했는데, 오늘은 7시반에 출발해서 9시 30분에 도착했다.
더 일찍 출발하면 도착시간이 얼마나 줄어들지 궁금하다.
빨간버스의 배차 주기가 더 짧았다면 더 좋았을 것 같다.

지하철로만 오게되면 3번을 갈아타야하는데 빨간버스는 2번을 갈아탄다.
시간 차이가 거의 없지만 버스라는 단점이 존재하기 때문에 어떻게 와야할지 고민이다.

오늘도 화이팅!

'진짜 일기' 카테고리의 다른 글

2023.09.11  (0) 2023.09.11
2023.09.07  (0) 2023.09.07
2023.09.06  (0) 2023.09.06
2023.09.02  (2) 2023.09.02
2023.08.29  (0) 2023.08.29

오늘은 조금 일찍 일어났다.

뭔가 모르게 일찍 깼다.
뭔가 이상한 꿈을 꿨던것 같다.
뭔가 뒹굴거리기도 싫었다.
뭔가 그냥 일어나서 밥을 먹었다.
뭔가 카페를 빨리 와야할 것 같았다.

그냥 오늘은 알고리즘 문제만 주구장창 풀어야겠다.

'진짜 일기' 카테고리의 다른 글

2023.09.19  (0) 2023.09.19
2023.09.07  (0) 2023.09.07
2023.09.06  (0) 2023.09.06
2023.09.02  (2) 2023.09.02
2023.08.29  (0) 2023.08.29

젠장 어제 갑자기 면접이 금요일로 잡혀서 계속 딥러닝 관련 면접질문 내용만 뒤적거리고있다.
그래도 코테가 토요일에 있기때문에 한 두문제씩은 풀고 준비를 하고있다...
내일 면접은 어찌될지 모르겠다만 첫 면접이니만큼 질문들을 기억하고 적어놔야겠다.

문제는 이력서 내용을 리뷰했어야 하는데 아직 못했다... 뿌에ㅔㅔ
지금 시간부터 이력서 리뷰하고 기억에 남겨야겠다.

내일 화이팅! 

'진짜 일기' 카테고리의 다른 글

2023.09.19  (0) 2023.09.19
2023.09.11  (0) 2023.09.11
2023.09.06  (0) 2023.09.06
2023.09.02  (2) 2023.09.02
2023.08.29  (0) 2023.08.29

요즘 일상의 루틴을 만들고있다.
이유는 자연스럽게 공부하고, 집중하기 위해서다.

누군가는 강압적으로 제한이 있는 성장 방식이 필요하다는 생각을 갖고 있었고, 그렇게 실천하고 있었다.
하지만, 다른 여러사람들의 말을 듣다보니 절벽 끝으로 몰아붙여서 성장하는 것은 단기적인 성장력이 어마무시하지만,
이 방법이 익숙해서 계속하다 보면 절벽 끝에 있는 상황이 익숙해져서 편해지는 느낌이 들게되면, 점점 성장이 더뎌진다는 생각이 들었다.

나는 매번 마음속으로 "나는 할땐 잘해! 주어진 일은 나한테 성장을 불러일으켜!"라고 생각하면서 누군가(어떤 상황이) 나를 절벽 끝으로 몰아붙여 주기를 원했다. 그리고 절벽 끝이 익숙해졌다.

점점 성장곡선이 늘어지는 것을 체감하면서 꾸준한 성장을 도모하고자 일상 루틴을 만들어 실행에 옮기는 중이다.

내가 일상 루틴을 만드는 방식은 생각보다 간단했다.
"지금 식사는 무엇을 먹을까?", "식사를 한 뒤에 뭘하지?", "컴퓨터에 앉아서 뭘하고있는거지?", "내가 뭘 하고 싶은거지?"
의문문을 끊임없이 던진지 4일정도 되었다.

그렇게 정해진 루틴으로는 아래와 같다.

  • 아침으로 간장계란밥을 먹는다.
  • 씻고 카페에 간다.
  • 글을 쓴다.
  • TODO LIST를 정비한다.
  • 알고리즘 문제를 푼다.
  • 책을 본다.
  • 집에 간다.
  • 면접 질문 리스트를 공부한다.

아직 이후에 정할것들이 많다.

여기서 시간별로 정하는게 낫겠다는 생각이 들수도 있는데, 나는 그렇게 생각한다.
"시간은 내가 컨트롤할 수 있는게 아니다. 그러니까 내게 주어진 시간은 많으니 행위에 집중한 루틴은 시간표가 아니라 일상이 될 수 있다."

일상은 마냥 특별하지도 일반적이지도 않기 때문에 쉽게 루즈해지지 않을 수 있다고 생각한다.

이 글을 보는 사람은 시간표 혹은 루틴이 있는가? 묻고싶다.

'진짜 일기' 카테고리의 다른 글

2023.09.11  (0) 2023.09.11
2023.09.07  (0) 2023.09.07
2023.09.02  (2) 2023.09.02
2023.08.29  (0) 2023.08.29
7/23 일기  (0) 2022.07.23

9월이 시작되었다.
작성한 TODO LIST를 따라 뭔가를 막 하고있다.

어제 날이 정말 좋아서 카페에 가서 코딩 테스트 문제를 풀었다.
그리고 SKCT를 보고 코딩 테스트 준비를 하느라 바빴다.

SKCT는 막 수학, 언어 이런거 나올줄 알았는데 개발직군이라 인성검사만 했다.
뭐... MBTI검사하는 느낌이었고 말을 요리조리 바꿔서 질문을 하는데 ㅏ 다르고 ㅓ 다르게 대답할 수밖에 없는 말이 많았다.

푸쉬업도 못할때까지 했는데 24개.... 에혀 이렇게 몸이 쓰레기가 됬구나 라는 생각이 들었다.
꾸준히 푸쉬업 해야지.... 이번달까지 60개할 수 있었으면 좋겠다.
왜냐면 의경시험에서 1분에 68개 했던 기억이있기 때문이다.
한달로는 안되겠지만 그래도 60개정도는 가능할거같다.

오늘도 날이 너무 좋은데 기존에 있던 약속이 파토났다.
친구가 선배네 집 놀러가자 그랬는데 집안일이 생겼다고 한다.
나가서 친한 사람들 만나는 것도 좋지만, 집에있는것도... 헤ㅔ 돈도 없고,,,,헤ㅔ 코테 준비도 해야하고,,, 헤ㅔ
뭐 어쨌든! 주말 내내 집에서 아주 신나게 코테 문제만 풀거같다 ㅋㅋㅋㅋㅋ 와. 신.난.다.

9일에 SKT 코딩 테스트가 있으니까 어쩔수 없다.
시간이 남을때 코테 문제푸는거 만큼 생산적이면서 시간 잘 가고 머리 잘 굴러가는 것 만큼 없다...

뭐 오늘도 화이팅하고 내일도 화이팅하고 내 주변 친한 사람들 다 행복했으면 좋겠다.

'진짜 일기' 카테고리의 다른 글

2023.09.07  (0) 2023.09.07
2023.09.06  (0) 2023.09.06
2023.08.29  (0) 2023.08.29
7/23 일기  (0) 2022.07.23
7/19 일기  (0) 2022.07.19

글을 안 적은지 꽤 오래됐다는 것을 깨달았다.
다시 일기를 써보자..

내가 일기를 쓰는 이유가 뭔지 생각해 봤다.
이전에도 그렇고 지금도 그렇고 진행 방향을 알 수 없어서 그런 것 같다.

글을 쓰다 보면 뭔가 깨닫는 것이 생기지 않을까..
일단 오늘은 9월의 TODO LIST를 노션에 적을 것이다.
그리고 실행에 옮겨야겠지.


일단, 글을 쓰지 않을 때 어떤 일이 있었는지 적어보자.

42 Seoul의 마지막 과제 Transcendence는 3월에 마쳤다.
하지만, 마지막 시험은 보지 않았다.
왜냐하면 네이버 부스트 캠프 AI Tech에 들어갔기 때문이다.
이것만으로는 "그래서 왜 안 봤는데?"라는 생각이겠지만,,, 뭐... 너무 바빴다.
정해진 시간이 있어서 무언가 하기 힘들었다.

일단 그래서 6월 2일(?)쯤에 아마 블랙홀로 빠졌다.
사실 블랙홀로 간지 알게 된 건 슬랙에서 퇴출당했기 때문이다.
그때도 계속 바빴기 때문에 뭐... 신경쓸겨를이 없었다.

계속 바빴다고만 하는 것이 핑계 같지만 맞다.
지금 생각해 보면 할 수 있었던 것 같다.

네이버 부스트 캠프 AI Tech에서는 8주 동안 Python부터 시작해서 Numpy, Pytorch, Pandas로 기초를 학습할 수 있었다.
학습할 수 있었던 거지 내가 흡수할 수 있는 것은 대략 3할 정도..?면 많이 쳐준 느낌이다.
계속해서 대략 16주 동안은 딥러닝의 간단한 태스크들을 공부했다.
Classification, Object Detection, Semantic Segmentation, OCR, Multi-label Classification 등의 모델링을 주로 담당해서 진행했다.
사실 모델링이랄게 예전처럼 신나게 로직을 정리해서 코드를 짜는 것이 아니다.
모델을 가져와서 적용해 보고 성능이 잘 나오게 되면 논문을 읽고 어떤 놈인지 성격을 파악해 줘야 한다.

내가 구현할 게 아니고 이미 구현된 친구들을 가져와서 적용하고 특징을 파악하는 것만 해도 시간이 굉장히 많이 걸리기 때문에 4개의 Competition에서 살아남기 위해선 어쩔 수 없었다.

대략 5달 정도의 학습은 내가 온전히 받아먹지 못했고 3할 정도 소화했던 것 같다.
그래서 이후에 뭘 해야 할지 생각만 계속했다.
Python을 까볼까.. 논문을 찾고 구현해 볼까... 책을 읽고 수학, 딥러닝 기초 등을 공부할까... 이력서 수정해야 하는데....

결국 가장 쉬웠던 건 책을 사고 읽는 것이었다.
그래서 두 권을 빠르게 사버렸다. (딥러닝을 위한 수학, 밑바닥부터 시작하는 딥러닝1)
일단 두 책을 읽는데 사실 이해 안 되는 부분이 꽤 많다.
밑바닥부터 시작하는 딥러닝1은 그래도 많이 이해했지만, 수학을 다시 손에 잡고 머리를 돌리기는 아주 어려운 것 같다.
꾸준히 해서 기름칠해야겠다. (기록할 예정)

운동도 다시 시작해 보고, 코테 준비도 다시 할 거고, 면접 준비 질답도 시작할 거고 뭐 다 할 거다.
계획은 창대하겠지만 끝이 어떻게 될지.... 뭐 그냥 잘되도록 노력하자

잘할거야
난 잘할 거니까 믿고 잘해보자!

'진짜 일기' 카테고리의 다른 글

2023.09.06  (0) 2023.09.06
2023.09.02  (2) 2023.09.02
7/23 일기  (0) 2022.07.23
7/19 일기  (0) 2022.07.19
7/13 일기  (0) 2022.07.13

일반적으로 하나의 Process는 하나의 Thread를 가지고 작업을 수행한다.
하지만, Multi Thread란 하나의 Process에서 다중의 Thread가 동시에 작업을 수행하는 것을 의미한다.
또한, Multi Process는 여러 개의 CPU를 사용하여 다중의 Process를 동시에 작업을 수행하는 것을 의미한다.

Multi Thread, Multi Process 모두 동시에 어떤 작업을 한다는 점이다.
여기서 둘의 차이는 독립적인 메모리 공간을 갖고 있느냐의 차이이다.
Multi Process는 각자 독립적인 메모리 공간을 갖지만, Multi Thread는 Thread가 상위 Process의 메모리 공간을 공유하여 사용한다.(Stack 메모리 공간은 예외)

이처럼 Multi Thread는 메모리 공간의 낭비가 적고 다수의 작업을 동시에 진행할 수 있다는 장점이 있다.


Context Switching

 

컴퓨터가 동시에 처리할 수 있는 최대 작업수는 CPU코어의 수와 같다.
그럼 CPU코어 보다 더 많은 Thread를 사용하게 되면 정해진 순서대로 작업을 번갈아가며 수행한다.

이렇게 각각의 Thread가 교체될 때, Thread 간의 Context Switching이라는 것이 발생한다.
현재 Thread의 작업을 하는 중에 다른 Thread의 작업을 하려면 현재 Thread의 작업을 저장하고, 다음 Thread를 불러오는 과정을 말한다.

이런 과정으로 알 수 있는 점은 무조건 Thread가 많다고 좋은 것이 아니라는 것이다.
저장과 불러오기의 과정에서 걸리는 시간이 커지게 되면 효율이 저하될 수밖에 없기 때문이다.


C#의 Thread Pool

 

사전에 일정 개수의 Thread를 만들어 놓고 작업 요청하게 되면, 사용가능한 Thread를 할당하여 수행하게 된다.
즉, 작업 요청 시에 Thread를 매번 만드는 것이 아니라 대기 중인 Thread를 불러서 작업을 요청하는 것이다.

그러면, Thread Pool의 최대 개수를 넘어선 작업을 요청하게 되면 작업은 점점 쌓이게 된다는 문제가 있다.
또한, Thread가 무한루프를 돌아도 문제가 생긴다.


이야기 예시

 

사장(CPU)과 알바관리 매니저(Process), 알바(Thread)가 하나의 가게를 맡았다고 하자. 끔찍하네

사장은 매니저에게 이것저것 시키게 된다.
매니저는 사장에게 들은 일거리를 알바에게 시킨다.
근데 알바는 일의 순서대로 차근차근 일을 하지만 몸이 하나기에 한 번에 여러 가지 일을 할 수 없다.
그렇기에 알바가 일을 해도 일이 끊임없이 쌓이게 된다.

매니저는 일이 너무 많이 쌓여서 효율이 없다고 판단하게 되어 알바를 여러 명 쓰게 된다.
근데 하루는 일이 평소보다 많이 안 들어와 놀고 있는 알바가 보이게 된다.
어떤 날은 일이 많고 어떤 날은 일이 많지 않다.
그래서 매니저는 알바들을 합숙시키게 된다.(Thread Pool)
이렇게 일이 밀릴 때마다 한 명씩 내려와 일을 시키는 양상이 돼버린 것이다.

이렇게 사람으로 생각하면 끔찍하지만 하나의 부품들로 생각하면 편하고 효율적인 것이다.

대표적인 OpenGL의 예제들을 살펴보면 아래와 같은 형태의 데이터를 Vertex Shader에 전달해준다.

std::vector<glm::vec2>	texCoord = {
	1.0f, 1.0f,
	1.0f, 0.0f,
	0.0f, 0.0f,
	0.0f, 1.0f
}

단순하게 생각해보면 Texture를 가져온 데이터를 좌표값을 나타냈을 때,  아래처럼 생겼기에 화면에 맞추는 작업이구나 하고 넘어갈 수 있다.

left  top(0.0f, 1.0f)
right top(1.0f, 1.0f)
left  bottom(0.0f, 0.0f)
right bottom(1.0f, 0.0f)

 

하지만, 이렇게 맞춰서 변환하는 과정은 생각보다 길고, 복잡할 수 있다.


Tangent Plane

구로 예시를 들어서 말하는 것으로 하겠습니다.

구에서 임의의 한 점과 맞닿는 평면, 이 평면이 Tangent Plane이다.
또한, 이런 평면을 좌표계 기준으로 잡는 공간을 Tangent Space라고 한다.


OpenGL에서 Tangent Plane이 이 어떻게 쓰일까?

OpenGL에서는 3개의 Vertex로 이루어진 삼각형을 하나의 Tangent Space에 존재한다고 생각한다.
그래서 주어진 Vertices와 Indices를 기준으로 Tangent Space를 계산한다.

주어진 Vertices와 Indices에 따라 2개의 벡터를 생성[$E_{1}, E_{2}$]하고,
주어진 Vertices에 대한 TexCoord에 따라 u와 v를 2개씩 생성[$\begin {bmatrix} u_1 & v_1 \\ u_2 & v_2 \end {bmatrix}$]한다.

여기서 우리는 Tangent, Bitangent Vector를 구할 수 있다.

$\begin {bmatrix} E_{1x} & E_{1y} & E_{1z} \\ E_{2x} & E_{2y} & E_{2z} \end {bmatrix} = \begin {bmatrix} u_1 & v_1 \\ u_2 & v_2 \end {bmatrix} \begin {bmatrix} T_x & T_y & T_z \\ B_x & B_y & B_z \end {bmatrix}$

사실 이렇게 보면 잘 모르겠어서 여러 가지로 생각해봤다.

  1. 이 변환 과정은 한 번에 진행되는 것이 아니다.
  2. 여러 가지 좌표계의 변환을 통해 생긴 것.
  3. 단순히 변환 행렬을 구한 것이지만 여러 개의 혼합된 버전일 것.
  4. 해당 좌표계로 이동, 좌표계 방향에 맞춰 회전, 해당 크기로 축소/확대의 혼합
  5. 3차원에서 2차원으로 변환하는 것이기에 이렇게 구하는 것.
  6. 한 번에 변환하는 행렬을 구한 것일 듯?

결국 구하고 싶은 행렬을 우린 TB Matrix라고 생각했을 때, 생성된 uv Matrix의 역행렬과 2개의 Vector로 이뤄진 Matrix를 곱하면 구할 수 있다.

$\begin {bmatrix} T_x & T_y & T_z \\ B_x & B_y & B_z \end {bmatrix} = \begin {bmatrix} u_1 & v_1 \\ u_2 & v_2 \end {bmatrix} ^{-1} \begin {bmatrix} E_{1x} & E_{1y} & E_{1z} \\ E_{2x} & E_{2y} & E_{2z} \end {bmatrix}$


하지만 이와 같은 과정에서 TBN의 Space에서 서로가 직교하지 않을 수 있다.
그렇기 때문에 그람-슈미트 직교화를 통해 각각의 벡터가 직교하도록 만든다.

위의 방법처럼 한 번에 구하는 것이 아니라, Tangent만 구해서 Shader로 넘겨준다.
이후 Shader에서 Normal과 Tangent를 Cross Product 하면 Bitangent의 값이 나온다.

'OpenGL' 카테고리의 다른 글

Normal Vector의 변환 행렬  (0) 2022.11.14
OpenGL[Lighting]  (0) 2022.10.18
OpenGL[Coordinate System]  (0) 2022.10.18
OpenGL[02](First Triangle)  (1) 2022.10.12
OpenGL[01](Shader)  (1) 2022.10.12

Plane Equation

한 평면 위의 임의의 Vector와 평면의 법선 벡터(Normal Vector)는 서로 수직 한다.
즉, $ V_{평면 위의 임의의 Vec} \cdot N_{평면의 법선 벡터} = 0$ 를 만족한다.


Vertex Position의 변환 행렬[M]은 평면 위의 임의의 점을 변환시켜주는 변환 행렬이다.

변환 전 : $N \cdot V = 0$
변환 후 : $N' \cdot V' = 0$

여기서 법 선 벡터[N]와 평면 위의 임의의 Vector 사이에 $M^{-1} M$를 삽입한다.($M^{-1} M = I$)
$NM^{-1} MV = 0 \rightarrow \  NM^{-1} V' = 0 = N'V' \rightarrow \ NM^{-1} = N'$
$(M^{-1})^{T} N = N'$


결론

법선 벡터의 변환 행렬은 Vertex Position의 변환 행렬의 역행렬을 전치시킨 행렬이다.
[$(M^{-1})^{T}$]

 

'OpenGL' 카테고리의 다른 글

Texture Coordinate  (1) 2022.11.14
OpenGL[Lighting]  (0) 2022.10.18
OpenGL[Coordinate System]  (0) 2022.10.18
OpenGL[02](First Triangle)  (1) 2022.10.12
OpenGL[01](Shader)  (1) 2022.10.12

배우는 이유?

 

우리가 사용하는 어떤 앱을 만들기 위해 서버, 데이터 베이스 등 몇 개의 앱을 사용하는데,
이런 것들을 한꺼번에 할 수 없을까?

이런 상황을 위해 각각의 실행하되, 격리된 환경에서 실행되게 하면 되지 않을까?
그렇게 격리된 환경에서 네트워크로 연결해서 필요한 정보를 주고받으면 되겠구나.
격리된 환경에는 운영체제가 존재하진 않지만 앱을 실행시키기 위한 것들만 존재하게 하면 많은 것들을 아낄 수 있다.

이렇게 하나의 컴퓨터에 여러 개의 격리된 환경을 만들 수 있게 하는 것이 Docker다.

하나의 컴퓨터는 Host, 격리된 각각의 환경을 Container라고 칭한다.
그렇다면 Host와 Container의 운영체제는 같아야 하는가? 아니다.

Docker는 기본적으로 Linux에서 돌아간다.
그래서 Mac, Windows에서 Docker를 설치하면 경량화된 Linux가 가상화되어 그 위에서 Docker가 실행되는 것이다.

그렇다면, VM과 다를 것이 없을 텐데 왜 사용하는가? 아니다.
VM과는 명백하게 다른 점이 있다.

  1. VM은 운영체제를 완전히 설치해야 하기 때문에 어떤 운영체제도 받을 수 있다.
    • Docker는 Linux의 위에서만 돌아가기 때문에 Linux계열의 운영체제만 지원된다.
  2. VM은 Host와 완전히 분리되어 있다.
    • VM은 논리적 가상화로 인해 운영체제를 완전히 설치해서 사용한다.
    • Docker는 Kernel의 공유로 Host의 운영체제에서 부족한 부분의 운영체제를 설치해서 사용한다.
      • 즉, Docker에서의 명령은 Host를 통해 실행된다.
  3. VM은 해킹당해도 문제없지만, Docker는 해킹당하면 Host가 위험하다.
    • VM은 Host와 분리되어 있기에 영향이 없지만, Docker는 Host와 연결되어있기에 다른 컨테이너 또한 위험하다.

 

결과적으로, 관리만 잘하면 자원의 낭비 없이 효율적으로 사용하는 유용한 도구가 Docker인 것이다.

 


네트워크

 

내 컴퓨터에서 어떤 웹페이지를 띄운다면 Host의 Port를 통해 접근해서 어떤 html 파일을 열게 된다.
근데 이런 과정을 Docker를 이용해서 한다면,
Host의 Port를 통해 들어가면 해당 Port와 연결된 Container의 Port로 들어가서 Container에 저장된 어떤 html을 열게 된다.

이런 Host와 Container의 Port를 연결하는 과정을 Port-Forwarding이라 한다.

ps. 호스트와 컨테이너의 파일 시스템을 연결시킬 수 있는 방법도 있다.


Docker의 Image 만드는 법

 

Image는 Container를 만들기 위한 설계도로 모든 파일과 설정값을 갖고 있다.
또한, Image는 변하지 않고, 여러 개의 컨테이너를 생성할 수 있다.
이런 Image는 Container에서 commit을 이용해서 생성할 수 있고, Dockerfile를 build 하여 생성할 수 있다.

Container에서의 commit은 현재 상태를 백업하는 용도로 Image를 생성하는 느낌이다.

Dockerfile은 Image의 초기 설정값, 실행할 명령어 등을 문서상으로 작성해놓은 것.


Dockerfile 작성법

 

FROM ubuntu:20.04

Docker의 Image 환경을 지정하는 방식이다.

- Image의 환경을 Ubuntu의 20.04 Version을 사용하는 것이다.

RUN apt update && apt install -y python3

Image의 환경에서 실행되는 명령어인데, 실행할 때마다 Layer가 생성되기 때문에 한 줄에 여러 개의 명령어를 작성하는 것이 좋다.
Build 되는 시점에 실행되는 명령어 -> Image에 반영

- 현재 apt의 상태를 최신으로 해준 뒤 python3을 설치해주는데, Yes/No의 대답에 항상 Yes를 해주겠다는 내용이다.

WORKDIR /var/www/html

Shell에서 "mkdir -p /var/www/html"과 같은 명령어이다.

- 해당하는 폴더가 없다면 만들어주고, 해당 폴더로 현재 경로를 옮겨준다.

COPY ["index.html", "."]

- Host의 현재 경로에서 첫 번째 변수를 Image의 현재 경로에 복사한다.

CMD ["python3", "-u", "-m", "http.server"]

Container를 만들 때 실행되는 Default 명령어 -> Container에 반영
즉, Docker Run 하면서 명령어를 지정하면 실행되지 않는다.

- python3의 기본 Web Server를 실행시킨다.(8000번 Port로 연결된다.)

Dockerfile 실행 방법

 

docker build -t <Image의 이름> <Dockerfile의 경로>
// 경로의 Dockerfile을 찾아 실행시켜 Image를 생성한다.

docker rm --force <Container의 이름>
// 만약 생성할 Container가 이미 있는 이름이라면 제거한다.

docker run -p <Host의 Port>:<Container의 Port> --name <Container의 이름> <Image의 이름> (<명령어>)
// Container를 생성하는데, Port-Forwarding해준 뒤, 이름 지정, 명령어를 실행시켜 준다.(명령어는 생략 가능)

Docker Compose를 이용한 Docker Container 제어하기

 

실제 Docker Container는 하나의 프로그램을 실행하는데, 하나의 프로그램으로 서비스가 된다면 Docker는 필요하지 않았을 것 같다.
예시로 WordPress를 컨테이너로 만들게 되면, SQL이 필요하여 또 하나의 컨테이너가 필요하게 된다.
그렇게 두 개의 컨테이너가 만들기 위해 Dockerfile을 실행시킬거나 Image를 가져올 때 몇 개의 명령어를 위해 Docker-compose.yml파일을 만들게 된다.

  • 컨테이너의 이름 설정
  • 컨테이너 생성 순서 설정(의존성)
  • Port-Forwarding(Host와 Container 간의 통신이 필요한 경우)
  • Volume 공유
  • 컨테이너 환경 변수 설정
  • 네트워크 생성, 설정

 


왜 Inception에서 MariaDB, Nginx, Wordpress를 사용할까?

 

  • Nginx는 웹 서버를 위한 도구
  • Wordpress는 손쉽게 웹 사이트를 만들 수 있는 도구
  • MariaDB는 관계형 데이터 베이스 관리를 위한 도구
    • 데이터 베이스 : 컴퓨터 시스템에서 전자적으로 저장되는 구조화된 정보 또는 데이터의 조직화된 모음

Wordpress의 모든 정보는 데이터 베이스에 저장, 저장된 데이터는 웹 사이트를 만든다.
웹 사이트를 구성하는 대부분이 데이터 베이스에 저장되어 있다.
예를 들면, 사용자 이름, 비밀번호, 포스트, 페이지, 댓글, Wordpress 구성 설정 등

작동방식

사용자가 웹 사이트를 방문하면 해당 브라우저가 Nginx에게 Request를 전달하고,
Nginx는 받은 Request를 WordPress에게 전달해준다.
그리고 WordPress는 Request를 받아 MariaDB에서 필요한 데이터를 추출한다.
추출된 데이터에 따라 웹 사이트를 만들어 Nginx로 보내진 뒤 사용자에게 보여준다.

 

'42일기' 카테고리의 다른 글

kqueue의 사용법  (0) 2022.07.23
I/O Multiplexing  (0) 2022.07.23
ft_containers[Red-Black Tree]  (1) 2022.04.29
ft_containers[Map]  (0) 2022.04.26
CPP [템플릿]  (0) 2022.03.02

+ Recent posts