[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로 접속할 수 있다.

Rust 프로그래밍에서 map() 활용

Python이 그러하듯 Rust도 declarative programming(선언형 프로그래밍)을 지원한다. 그 중 map()은 이러한 코딩스타일의 대표처럼 사용되고는 하는데, 이것을 이용하면 길고 장황한 코드를 간결하게 나타낼 수 있다.

기본적 사용법

1 부터 10까지 1씩 증가하는 값을 가진 i32 형의 10칸짜리 배열 arr이 있다고 할 때, 그 안에 있는 각 원소들에 2를 곱하는 코드이다.

// 배열의 각 요소들에 x2를 수행하고 결과를 출력.
// 실행결과:
// Doubled array: [2, 4, 6, 8, 10, 12, 14, 16, 18, 20]

fn main() {
    // i32 type 배열 선언.
    let arr: [i32; 10] = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];

    // map()을 사용해서 각 element들에 x2를 수행.
    let d_arr = arr.map(|x| x * 2);
    println!("Doubled array: {:?}", d_arr);
}

위의 코드는 Python과 같은 다른 언어에서도 사용하는 형식을 가지고 있어서 직관적이고 그 내용을 이해하기도 비교적 쉽다. 그렇다면 vector에 대해 같은 코드를 작성하면 어떨까? 10칸짜리 vector, vec를 만들고 동일한 동작을 수행해 보도록 하자.

// 벡터의 각 요소들에 x2를 수행하고 결괄르 출력.
// 실행결과:
// Doubled vector: [2, 4, 6, 8, 10, 12, 14, 16, 18, 20]

fn main() {
    // Vector를 선언하고 1 부터 10까지 값들로 초기화.
    let vec = vec![1, 2, 3, 4, 5, 6, 7, 8, 9, 10];

    // map()을 사용해서 각 element들에 x2를 수행.
    let d_vec = vec.iter().map(|x| x * 2).collect::<Vec<_>>();
    println!("Doubled vector: {:?}", d_vec);
}

앞에서의 배열에 대한 map() 연산과 달리 뭔가 복잡해 졌다. 10번째 줄을 보면, map()을 호출하기 전에 iter()를 통해서 먼저 iterator(반복자)를 받고, 그 다음에 map()의 내용을 lambda로 수행한 다음에 collect::<Vec<_>>()라는 기괴한 구문으로 끝을 맺고 있다.

The “Lazy Pipeline”

이와 같이 data soruce로 부터 반복자를 받아서 map()을 통해 형태를 변경하고 다시 collect()로 넘겨 최종 처리하는 패턴(Create – Transform – Consume)이 Rust에서 자주 사용되는데 이것을 “Iterator Bridge” 패턴 혹은 “Lazy Pipeline”이라고 부른다.

이렇게 복잡한 pipeline을 거치는 이유는 크게 두가지 정도를 생각해 볼 수 있는데, 첫번째는 원하는 목적에 따라 각 단계의 함수(메소드)들을 다른 종류로 대체할 수 있기 때문이고 두번째는 앞서 살펴본 array와 달리 컴파일 시간에 그 크기가 정해지지 않는 동적 타입에 대해 실행시간을 최대한 미루는 게으른 처리(lazy evaluation)을 이용하여 성능을 향상시키기 위함이다.

각 함수(메소드)들의 대체

위의 예제에서는 Vector type의 source에 대하여 x2라는 transformation을 수행하고, collect::<Vec<_>>()로 consume해서 새로운 vector를 생성해 냈다. 반복자를 호출하는 방법에도 소유권을 넘겨주는 지 혹은 빌려오는지에 따라 iter_into() 혹은 iter()와 같은 다양한 종류의 반복자 반환 메소드를 사용할 수 있고, transformation을 수행하는 메소드도 map() 뿐만 아니라 특정한 조건을 만족하는 원소를 걸러내는 filter()같은 메소드들을 사용할 수 있으며, 최종단의 consumer 역시도 새로운 container를 만들어 내는 collect()외에도 요소의 갯수를 반환하는 count() 나 요소의 합을 계산하는 sum() 같은 다양한 메소드들로 목적에 맞게 파이프라인을 구성할 수 있다.

동일한 패턴을 유지하면서 vector내부에 있는 짝수의 총 합을 계산하는 다음 코드를 한번 보자.

// 벡터안의 짝수만 걸러서(filter) 합을 구하기
// 실행결과:
// Sum of all even numbers: 30

fn main() {
    let vec = vec![1, 2, 3, 4, 5, 6, 7, 8, 9, 10];

    let sum = vec.iter().filter(|x| *x % 2 == 0).sum::<i32>();
    println!("Sum of all even numbers: {}", sum);
}

게으른 처리 (Lazy Evaluation)

Adapter인 map() 혹은 filter()로 호출한 구문은 consumer(collect(), fold(), sum(), count(), for loop 등)을 만나기 전까지는 아무런 수행도 하지 않았다가 consumer를 만나고 나서야 동작을 수행하게 된다. 이러한 동작은 pipeline이 구성된 후에 수행되기 때문에 불필요하게 중간상태를 보관하기 위한 메모리를 할당할 필요 없이 최적화된 코드 수행을 할 수 있도록 해준다. 실행시간에 크기가 변화하는 Vector와 같은 container를 감안할 때, 코드 수행단계마다 처리해서 임시 메모리에 쌓아두는 것 보다, 필요 할 때까지 미루어 뒀다가 최종 상태를 감안해서 처리하는 게으른 처리는 메모리 소모와 성능면에서 좋은 전략이 될 수 있다.

Option과 Result에 대한 map() 사용

언뜻 보면 일관성이 없어 보이기도 하지만, Option과 Result에도 map()을 사용할 수 있는데, 이는 Option의 Some()이나 Result의 Ok() 상태 처럼 정상동작한 경우에 대해 수행할 동작을 정의하고자 할 때 사용할 수 있어서, if let 구문이나 match 구문을 대체하여 코드를 간결하게 유지할 수 있도록 해준다.

// 실행결과:
//the value is SOME: 'some value'
//the result is OK: Result was good

use std::io::{Error, ErrorKind};

fn main() {
    // Option, map()
    let opt = Some("some value");
    //let opt: Option<String> = None;
    opt.map(|x| println!("{}", format!("the value is SOME: '{x}'")));

    // Result, map()
    let res: Result<String, Error> = Ok("Result was good".to_string());
    //let res: Result<String, Error> = Err(Error::new(ErrorKind::Other, "Some error"));
    let _ = res.map(|x| println!("{}", format!("the result is OK: {x}")));
}

Conclusion

Rust에서 사용되는 map()의 활용에 대해 살펴 보았다. Container에 대해 map()을 사용하는 것은 비교적 우리에게 익숙하지만, Option / Result에 map()을 사용하는 개념은 상대적으로 그렇지 않은데, 많은 설명들에 따르면, 이것은 “상자 속에 들어 있는” 어떤 값에 대해 그 내부를 직접 들여다 보지 않고 적용한다는 점에서 container와 Option, Result 공통으로 적용할 수 있는 선언형 프로그래밍의 철학이 적용된 것이라고 한다.

Release Please – Change log 생성 자동화

팀에서 Conventional commit을 따르고 있다면, 이것을 활용해서 change log를 만드는 것과 같은 귀찮은 일들을 자동으로 수행해 주는 도구들이 많이 있다. 이 포스팅에서는 그 중에서도 GitHub에서 사용하기에 편하다는 release-please를 Rust project에 적용해 본 내용을 다룬다.

사전 준비

  • GitHub PAT(Personal Access Token)

GitHub -> Settings -> Developer settings -> Personal access tokens -> Fine grained tokens에서 생성, contents, issues, pull-requests 권한을 부여한다. 이렇게 생성한 PAT를 Project -> Settings -> Environments에서 secret key로 등록해 둔다. 여기서는 PLEASE_REPLEASE_TOKEN 이라는 이름으로 설정했다.

  • Version Tag

Cargo.toml에 보면 version field가 있는데 현재 설정된 이 값에 맞춰서 GitHub에 Tag를 생성한다.

GitHub workflow 만들기

release-please는 workflow로 대기하면서 병합 브랜치(주로 main)에 코드가 들어 올 때 마다 이것을 감지해서 changelog를 작성하는 PR을 업데이트 한다. 이를 위해 다음과 같이 GitHub workflow를 하나 만들어 주고 서버로 commit한다. 아래의 예제에서 ci_keys는 앞서 생성한 PAT인 RELEASE_PELASE_TOKEN이 secret key로 들어 있는 environment이다.

동작확인

GitHub workflow가 main branch에 병합되면, 잠시 후에 release-package bot이 만든 PR이 만들어 지고, 여기에는 이전 버전 부터 현재까지의 변경 내역이 기록된다. 또한 이후에 main branch로 들어오는 모든 수정사항들도 기록된다.

사소한(?) 문제들

현재까지 발견한 두개의 문제점은:

  • 첫째. 리스트에 같은 커밋의 내용들이 두개씩 중복해서 나타난다.
  • 둘째. feat / fix 외의 다른 conventional commit들이 track되지 않는다.

첫번째 문제점의 원인은 PR을 merge할 때 default 값인 “Create a merge commit” 버튼으로 병합을 실행했기 때문에 작업 커밋 외에도 merge commit이 change log에 남았기 때문이다. release-please의 문서에서도 제안하듯, “Squash and merge”로 병합을 수행하면 커밋의 내용이 두번씩 중복되어 리스팅되는 문제를 막을 수 있다.

두번째 문제는 feat과 fix commit만 changelog에 올리는 것이 Release Please의 기본동작이기 때문인데 이것을 수정하고 싶다면 다음과 같은, release-please-config.json을 작성해서 어떤 항목들을 지원할 것인지 설정할 수 있다.

다음은 feat / fix외에도 perf / refactor / ci /chore 모두를 change log에 올리도록 하는 설정이다.

{
  "packages": {
    ".": {
      "release-type": "rust",
      "extra-types": ["feat", "fix", "perf", "refactor", "ci", "chore"],
      "bump-patch-for-types": ["refactor", "perf", "ci"],
      "bump-minor-pre-major": true,
      "changelog-sections": [
        { "type": "feat", "section": "Features", "hidden": false },
        { "type": "fix", "section": "Bug Fixes", "hidden": false },
        { "type": "perf", "section": "Performance Improvements", "hidden": false },
        { "type": "refactor", "section": "Code Refactorings", "hidden": false },
        { "type": "ci", "section": "CI Updates", "hidden": false },
        { "type": "chore", "section": "Miscellaneous", "hidden": false }
      ]
    }
  }
}

이 파일을 만들 때는 pair로 .release-please-manifet.json도 만들어 주는 것이 좋다고 해서 함께 만들어 주었다. 그 내용은 다음과 같다.

{
  ".": "1.0.1"
}

주의: release-please-config.json으로 제어할 때 주의해야 점이 있는데, 이 파일에서 release-type을 명시하고 있으므로, CI file에서는 release-type: rust반드시 삭제해 주어야 한다. 만약 이 부분이 있다면 충돌 때문에 설정한 config대로 동작하지 않고 default 동작으로만 동작 하게 될 수도 있다. 만약 잘 동작하지 않는다면 이부분을 확인해 보자.