Cloud Computing On Demand

깃허브 Github 에 공개되어 있는 코드를 개량할 때, 회사의 Git 에 등록된 과제의 기능을 개발할 때 우리는 포크 Fork 를 통해 원격 저장소의 코드를 내 저장소로 옮긴후 작업을 하게 됩니다. 

내 저장소에 옮겨진 코드는 필요에 따라 여러개의 브랜치 Branch 로 나뉘어지고, 개별 브랜치들은 내 저장소의 마스터 Master 브랜치와 머지 Merge 후 원격 저장소에 병합 요청을 하거나, 개별적으로 머지 요청을 하게 됩니다.

보통은 이런 절차를 따르기만 하면 문제가 없습니다. 하지만, 내가 포크한 소스코드의 원본 소스코드가 다른 사람에 의해 변경이 진행되고 원격 저장소에 병합된 내용이 등록되었다면 변경된 코드를 내 저장소로 동기화 할 필요가 있습니다.

지금부터 아래의 4단계를 통해 동기화를 진행해 보도록 하겠습니다.

1단계 - 원본 저장소 등록하기 : 업데이트된 파일을 가져오기 위해서 원본 저장소를 로컬 환경에 원격 저장소로 등록합니다

2단계 - 원본 저장소 변경분 로컬로 가져오기 : 업데이트된 파일을 가져오는 방법을 설명합니다

3단계 - 로컬 환경에서 원본 저장소와 포크한 저장소 병합하기 : 두 브랜치를 하나로 합칩니다

4단계 - 포크한 저장소를 원격의 git 에 업데이트 : 변경된 내역을 Push 합니다

1단계 - 원본 저장소 등록하기

우선 작업중인 환경에 원본 저장소를 원격 저장소 Remote Repository 로 등록해야 합니다.

아래의 예는 SSH 로 저장소의 주소를 등재한 경우입니다만, https 로 시작하는 주소를 쓰는 경우도 방법은 다르지 않습니다. 

// 등록된 저장소 확인
$ git remote -v
origin  git@git.mycompany.com:nopd/AwesomeApp.git (fetch)
origin  git@git.mycompany.com:nopd/AwesomeApp.git (push)

// 원격 저장소를 Upstream 으로 등록
$ git remote add upstream git@git.mycompany.com:SAJANGNIM/King.git
...
$ git remote -v
origin  git@git.mycompany.com:nopd/AwesomeApp.git (fetch)
origin  git@git.mycompany.com:nopd/AwesomeApp.git (push)
upstream  git@git.mycompany.com:SAJANGNIM/King.git (fetch)
upstream  git@git.mycompany.com:SAJANGNIM/King.git (push)

2단계 - 원본 저장소 변경분 로컬로 가져오기

원격 저장소를 등록했으면 이제 원본 저장소의 변경된 내용을 로컬로 가져올 차례입니다. 변경된 내용을 가져오기 위해서 우리는 git fetch 명령을 사용할 예정입니다.

아래 명령을 수행하면 원격 저장소, 즉 upstream 저장소의 파일이 로컬에 적재됩니다. 

// 원본 저장소를 upstream 으로 저장했으니 아래와 같이 호출합니다. 
// 파일은 upstream 의 master 브랜치에 저장되었습니다. 
//
$ git fetch upstream master
Enter passphrase for key '/blahblah/.ssh/id_rsa': 
remote: Counting objects: 9, done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 9 (delta 7), reused 0 (delta 0)
Unpacking objects: 100% (9/9), done.
From git.mycompany.com:SAJANGNIM/King.git
 * [new branch]      master     -> upstream/master
 
 

3단계 - 로컬 환경에서 원본 저장소와 포크한 저장소 병합하기

2단계 까지 마쳤으면 1) 포크한 저장소 (origin) 의 로컬 환경 파일들과 2) 원본 저장소의 파일들이 로컬 환경에 준비가 된 것입니다.

이제 로컬 환경에서 변경된 파일을 합쳐주면 되겠죠? 포크한 저장소로 브랜치를 변경하고 git merge 명령으로 로컬 환경의 두 저장소 파일을 합치겠습니다.

참고로 브랜치 단위로 머지가 되는 것이니 포크한 저장소의 master 브랜치가 아닌 다른 브랜치를 upstream 의 브랜치와 합쳐도 무방합니다. 필요에 따라 선택해 주면 되는 부분입니다. 

// 포크한 저장소의 로컬 브랜치로 환경을 변경합니다
// 아래 명령에서 master 는 origin/master 브랜치입니다
//
$ git checkout master
Switched to branch 'master'

// 현재 브랜치 (origin/master) 에 원본 브랜치 (upstream/master) 의 변경분을 합칩니다
//
$ git merge upstream/master
Merge made by the 'recursive' strategy.
 apps/modal/Request.vue | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

4단계 - 포크한 저장소를 원격의 git 에 업데이트

이제 로컬 환경은 원본 저장소의 최신 변경 내역이 반영된 따끈따끈한 저장소가 되었습니다.

로컬 환경이 원래의 집이 아니기 때문에 그 어디엔가에 있을 github 혹은 사내의 git 서버에 변경내용을 업데이트 해주어야 하겠죠?

git push 명령으로 소스코드를 원격 서버로 업데이트 해보겠습니다. 

// 손에 너무나도 익은 명령어를 입력해 봅니다
//
$ git push origin master

개발자가 아니고 git 보다는 SVN 이 더 익숙하다보니 여러가지로 시행착오를 많이 겪고 있습니다.

사실 개발자 직군도 아닌지라 필요한 순간에만 git 을 쓰다보니 분명 주요한 명령, 패턴에 대한 한계가 있는 것 같습니다.

비슷한 어려움을 겪는 분들에게 이 글이 도움이 되길 기원해 봅니다. 

혼자 사용하는 서버는 환경 설정을 자유롭게 할 수 있습니다. 자주 사용하는 경로의 지정이나 무언가를 설치했을 때 경로까지 익숙함을 바탕으로 찾아내는데 어려움이 없을 겁니다. 하지만, 서버의 운영체제 버전이 조금 다르다던가 계정 정책의 차이 등으로 패키지가 어디에 설치되었는지 헤메는 경우가 종종 생깁니다.

서버 환경으로 CentOS 를 자주 사용하다보니 패키지 설치는 거의 yum 을 사용합니다. 간혹 커스텀한 구성이 필요하여 직접 빌드하는 경우를 제외하면 관리가 편하기 때문에 yum 을 쓰는 편이죠. 오늘 아침, 자주 안들어가던 서버에서 mtr 패키지가 필요해서 yum 으로 설치했으나 실행이 되지 않는 문제가 있어서 패키지 설치 디렉토리를 찾느라 잠시 헤프닝이 있었습니다. 

// yum 은 패키지는 잘 설치해 주지만, 설치된 위치를 알려주진 않습니다
$ sudo yum install mtr
Loaded plugins: fastestmirror, security
Setting up Install Process
Loading mirror speeds from cached hostfile
 * centos-sclo-rh: mirrors.aliyun.com
 * epel: xxxx.xxxx.xxx
Resolving Dependencies
--> Running transaction check
---> Package mtr.x86_64 2:0.75-5.el6 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

======================================================================================================================
 Package                 Arch                       Version                            Repository                Size
======================================================================================================================
Installing:
 mtr                     x86_64                     2:0.75-5.el6                       base                      54 k

Transaction Summary
======================================================================================================================
Install       1 Package(s)

Total download size: 54 k
Installed size: 96 k
Is this ok [y/N]: y
Downloading Packages:
mtr-0.75-5.el6.x86_64.rpm                                                                      |  54 kB     00:00
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing : 2:mtr-0.75-5.el6.x86_64                                                                            1/1
  Verifying  : 2:mtr-0.75-5.el6.x86_64                                                                            1/1

Installed:
  mtr.x86_64 2:0.75-5.el6

설치는 잘 되었으나 Shell 환경에 지정된 Path 에 잡혀있지 않은지 실행이 되지 않았습니다. 패키지가 설치된 경로를 찾아야 할 때는 rpm 을 사용하면 좋습니다. rpm 과 grep 으로 패키지가 설치되어 있는지 찾아보거나 rpm 에 옵션을 지정하여 패키지 설치 경로를 확인할 수 있습니다. 

// 설치된 패키지의 이름을 확인
$ rpm -qa | grep mtr
mtr-0.75-5.el6.x86_64

// 설치된 패키지의 경로를 확인
$ rpm -ql mtr
/usr/sbin/mtr

일반적인 설치 경로인데 왜 실행이 안되었을까요? 그건 리눅스의 환경 변수중 명령어를 실행할 수 있는 경로의 집합을 나타내는 $PATH 에 경로가 빠져 있기 때문입니다. 한 번 확인해 보고 누락된 경우 추가를 해보도록 하겠습니다. 매번 전체 경로를 넣고 실행하기는 좀 번거롭겠죠? 실제로는 profile 설정 등에서 추가해 주어야 다음번 로그인시에도 경로가 추가된다는 점 잊지 마시구요.

// 꼴랑 두개 들어가 있네요
$ echo $PATH
/bin:/usr/bin

// 기존 $PATH 값에 콜론으로 연결하여 경로를 지정합니다
// 잘 들어갔는지 절대 알려주지 않으니 echo 로 다시 확인을...
$ PATH=$PATH:/usr/sbin
$ echo $PATH
/bin:/usr/bin:/usr/sbin

AWS 를 사용하면서 만나는 Global 서비스들이 여럿 있습니다. CDN 제품인 CloudFront 가 가장 대표적인 Global 서비스이고 CF 에서 사용할 수 있는 WAF (Web Application Firewall) 역시 Global 서비스 입니다. 이런 제품들의 특징은 사용자에게 가까운 곳에서 동작해야 효과가 좋다(?)는 점이죠.

최근 WAF 는 Version 2 를 출시하면서 기존의 WAF 는 WAF Classic 으로 부르기 시작했습니다. 몇 가지 변화들이 있지만 그 이야기를 하려는 것은 아니구요, 새로운 버전이 출시되면서 IAM Policy 에도 WAF v2 에 대응하는 부분이 추가되었고 Console 접근을 하려다 보니 생겼던 에피소드를 IAM Policy 를 살펴보면서 간단히 이야기 해볼까 합니다. 

IAM 에서 미리 정의하여 제공되는 Policy 중 WAF 와 관련된 것은 두가지가 있습니다. 하나는 AWSWAFFullAccess 이고 다른 하나는 AWSWAFConsoleFullAccess 입니다. 이들 Policy 를 사용하여 권한을 부여해 두었다면 Action 항목에 "wafv2:*" 가 자동으로 추가, 적용이 되었고 WAFv2 의 사용에 문제가 없어야 합니다. 개별 정책을 JSON 으로 정의했다면 명시적으로 "wafv2" 를 넣어줘야 합니다. 

# Policy : AWSWAFFullAccess

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "waf:*",
        "waf-regional:*",
        "wafv2:*",
        "elasticloadbalancing:SetWebACL",
        "apigateway:SetWebACL"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

문제는 기존 WAF Classic 은 화면 진입은 잘 되면서 에러 메세지가 눈에 안 띄는 곳에 나오면서 콘솔 진입시 위 정책이 충분치 않다는 것을 인지하기가 조금 어려웠습니다. 그런데 WAF v2 에서는 Unauthorized 메세지가 대박 크게 나오면서 마치 wafv2 정책이 제대로 들어가지 않은 것처럼 보이는 제보가 들어왔던 것이지요. 결론을 먼저 말하면 위 정책으로는 WAF Classic 이든 WAFv2 든 제대로 동작하지 않는게 정상입니다. 

# Policy : AWSWAFConsoleFullAccess

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "apigateway:GET",
        "apigateway:SetWebACL",
        "cloudfront:ListDistributions",
        "cloudfront:ListDistributionsByWebACLId",
        "cloudfront:UpdateDistribution",
        "cloudwatch:GetMetricData",
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:ListMetrics",
        "ec2:DescribeRegions",
        "elasticloadbalancing:DescribeLoadBalancers",
        "elasticloadbalancing:SetWebACL",
        "waf-regional:*",
        "waf:*",
        "wafv2:*"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

AWSWAFConsoleFullAccess 정책을 살펴보면 AWSWAFFullAccess 에 있는 정책들이 모두 들어가 있습니다. 추가로 WAF 적용의 주된 대상이 되는 API Gateway, CloudFront, ELB 관련한 항목들이 추가된 것이 보이는데요, 이들 정책이 있어야 AWS Console 화면 구성에 필요한 정보들을 가져올 수 있고 화면 접근시 Authorization 에러가 발생하지 않게 되는 것으로 생각됩니다. 한참을 헤메다 요 정책을 그룹에 추가해 주고나서 문제를 해소할 수 있었습니다. 

AWS 를 쓰다보면 IAM 에서 적절하고 충분한 권한을 주는 문제에 종종 부딪히게 됩니다. 적용된 정책을 확인하는 페이지도 제공하고 있긴 하지만 실제로 사용자들이 API 호출이나 Console 액세스시에 겪게 되는 문제와 연결고리를 찾기 힘든 경우도 종종 생깁니다. 결국은 경험치가 있어야 하는 것인가 하는 고민에 빠지게 되는 5월의 어느날입니다. 

[ AWS 자격증을 준비하신다면 - 3만명이 수강한 강의 추천드립니다! ]

[ WAF Classic 과 WAF v2 의 비교는 아래 블로그가 깔끔합니다! ]

본 포스팅은 소정의 수수료를 받을 수 있습니다.