카테고리 보관물: Linux

Smoke test를 위한 GitHub Self-hosted Runner 설정

Unittest가 개발 과정에서 논리를 점검하는데 유용하기는 하지만 이세상에는 integration test가 담당해야 하는 부분도 엄연히 존재한다. 각각의 컴포넌트들이 잘 작성되었다 할지라도 이것을 통합했을 때의 동작을 보장하는 것은 또 다른 이야기 이기 때문이다.

이 부분을 커버하기 위한 목적으로 가상의 데이터를 생성하고 프로그램의 처음 시작 부분부터 마지막 출력 부분까지(E2E) 점검하는 스크립트를 만들어 두었다. 문제는 unittest 만큼이나 이 스크립트를 자주 돌리지 않을 뿐 아니라 종종 커밋할 때 까먹는 다는 것이다.

가만, 이런 귀찮을 걸 안까먹으려고 CI를 설정해 두지 않았던가!

몇몇 리소스들을 찾아보니 GitHub workflow에서 제공하는 VM에서 docker를 돌리는 것에는 문제가 없다고 한다. 그래서 기존에 Lint와 Unitest를 수행하던 CI script에 추가로 E2E를 위한 smoke test script를 수행하는 부분을 추가하고 돌려봤더니 안타깝게도 docker instance 생성 후에 pip로 패키지들을 설치하다고 공간이 모자라서 오류가 나고 있었다.

VM에서 띄우는 docker 자체는 동작하지만 디스크 공간 같은 리소스는 충분히 주어지지 않는 것이다. 보다 높은 데이터 공간을 위해 비싼 요금제를 사용하는 것도 고려해 볼 수 있겠지만, 매번 CI를 수행할 때마다 docker instacne들을 모두 재생성 한다면 시간도 오래 걸릴 것이어서 별로 합리적인 해결 방안은 아닐 것 같다.

그래서 생각한 결론은 Self-hosted runner를 살리는 것이다. 이것 용도로 컴퓨터를 설정해야 하고 항상 네트워크에 물려 있도록 해야 하는 귀찮음은 있지만 비싼 GitHub 요금제나 instance 생성에 걸리는 시간은 아낄 수 있을것 이라 생각해서 이다.

Self-hosted runner를 설정하는 과정은 어렵지 않다. GitHub의 Actions 항목에서 Runners -> Self-hosted runner를 선택하고 “New runner” 버튼을 누르면 자세한 설정 명령어가 나오는데, 그대로 복사 붙여넣기만 하면 된다.

기존의 Lint / Unittest를 수행하는 CI는 그대로 GitHub에서 수행하고, 새로 추가된 smoke test만 self-hosted runner에서 돌리도록 해서 총 6분정도가 소요된다. 이 정도면 쓸만하다.

결론

GitHub 요금제를 올리는 방법도 있지만, 스스로 유지보수가 가능하다면 self-hosted runner를 사용해서 docker instance의 재생성을 막고 부가적인 환경 설정을 자유롭게 하는 방법도 고려해 볼만 하다.

WordPress “다른 업데이트가 진행중 입니다” 문제 해결

WordPress Update Lock

Update를 위해 Wrodpress가 설정하는 lock은 wordpress database의 wp_options table에 있다. 업데이트가 진행중이라는 메세지가 오랫동안 없어지지 않는 상태라면 wp_config.php에 적어둔 DB access 정보를 참조해서 해당 테이블에 접근해 core_updater.lock이 설정되어 있는지 확인해 보자.

mysql -u litcoder -p --database wordpress

SELECT * FROM wp_options WHERE option_name = 'core_updater.lock';

이 query에서 결과가 출력된다면 현재 lock이 걸려 있는 상태이다. 참고로 여기에서 option_value의 값은 lock이 설정된 unix time을 의미한다.

Lock 제거

반드시 현재 진행되고 있는 업데이트가 없고 이것이 비 정상적인 상황이라는 확신이 있을 때만 다음의 명령어로 lock을 삭제해 주자.

DELETE FROM wp_options WHERE option_name = 'core_updater.lock';

그리고 나서 재시도 해보면 해당 오류가 없어진 것을 볼 수 있을 것이다.

결론

시대가 시대인 만큼 wp-config.php를 읽어서 자동으로 lock을 해제해 주는 script를 “딸깍”으로 만들어 gist에 올려 두었다. 필요한 경우가 있다면 다음의 명령어를 터미널에 복붙하면 된다. 참고로 실행에 sudo 권한이 필요한 이유는 wp_config.php에 접근하기 위해서이다.

curl -sSL https://gist.githubusercontent.com/litcoder/\
27e0f3538762bfd3b0fcfdeea01d2867/raw/\
d7bb16761d4449408bb1c8dbee55931fccec20e7\
/wp-unlock-update.sh | sudo bash

[Tip] 포트 포워딩 설정 상태에서 VNC SSH Tunneling

댓글 남기기

VNC SSH Tunneling에 대해 다룬 적이 있었는데, macOS에서 기본 제공되는 Screen Sharing 같은 app으로 접속하려면 SSH 터널링을 설정하는 GUI가 없으므로 해당 포스팅의 “SSH Tunneling 설정이 없는 경우” 항목의 안내에 따라 다음과 같은 명령어를 터미널에 입력하고 localhost의 5999번 포트로 연결을 시도하면 된다고 했었다.

# SSH 터널링.
# 22번 SSH 포트를 통해 리모트의 5901번 VNC 포트를 로컬의 5999번 포트에 연결
ssh -L 5999:localhost:5901 <user_id>@<vnc_server_ip>

그럼 만약 22번이 아닌 포트 포워딩을 사용하고 있는 경우라면 어떻게 해야 할까?

사내에 있는 워크스테이션들에 각각 65530 부터 65531까지 포트로 access할 때 포워딩이 이루어 지도록 설정해 둔 상태라고 하면, 22번 포트가 아닌 특정한 포트로 포워딩을 수행하고 있으므로 이 값을 -p 옵션과 함께 작성해 주어야 한다. 예를 들어 포워딩하고 있는 포트의 번호가 65530이고 이를 통해 5901에서 돌고 있는 VNC를 내 localhost의 5999번 포트에 연결하고자 한다면 명령어는 다음과 같다.

# SSH 터널링.
# 65530번 SSH 포트를 통해 리모트의 5901번 VNC 포트를 로컬의 5999번 포트에 연결
ssh -L 5999:localhost:5901 -p 65530 <user_id>@<vnc_server_ip>

그리고 나서 macOS의 Screen Sharing에서는 다음과 같이 설정하고 VNC로 접속한다.

명령어가 너무 길다면

~/.ssh/config 환경 설정파일에 LocalForward를 다음과 같이 추가해 주면 매번 긴 명령어를 타이핑하지 않아도 된다.

# ~/.ssh/config
Host <host_name>
  HostName <vnc_server_ip>
  Port 65530
  User <user_id>
  LocalForward 5999 localhost:5901

이후 부터는 터미널에서 간단히 ssh <host_name> 명령어만 수행해도 Screen Sharing을 통해 VNC로 접속할 수 있다.

Litcoder

기억은 짧고 불완전 하다