아래 명령은 Ubuntu 기준이다.

우선 스왑 공간을 확인해 본다.

sudo swapon --show

아무것도 출력되지 않는다면 스왑 공간이 없다는 뜻이다.

스왑 공간으로 사용할 파일을 만든다.

$ sudo fallocate -l 1G /swapfile
$ sudo chmod 600 /swapfile

만든 파일을 스왑 공간으로 설정한다.

$ sudo mkswap /swapfile

Setting up swapspace version 1, size = 1024 MiB (1073737728 bytes)
no label, UUID=6e965805-2ab9-450f-aed6-577e74089dbf

swap on!

$ sudo swapon /swapfile

확인하면 제일 처음과 다르게 스왑 공간이 표시된다

$ sudo swapon --show

NAME      TYPE  SIZE USED PRIO
/swapfile file 1024M   0B   -2

여기까지 하면 현재 세션에만 스왑 공간이 적용된다. 영구적으로 변경해서 재부팅해도 적용되게 설정한다.

혹시 모르니 기존 설정 파일 백업부터 한다.

$ sudo cp /etc/fstab /etc/fstab.bak

스왑 공간 활성화 세팅을 /etc/fstab 에 추가한다.

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Logger.info([new_user: user_id, account_type: :admin])
Logger.info(%{new_user: user_id, account_type: :admin})

11:03:47.330 [info] [new_user: 5, account_type: :admin]

섞어 쓸 수 있을까?

Logger.error("We have a problem", [error_code: :pc_load_letter])

안타깝게도 이런 형식은 안 된다. 두 번째 인자는 metadata로 들어간다.

Logger.error([msg: "We have a problem", error_code: :pc_load_letter])

그래서 메시지까지 구조화해서 로깅했다.

On the footsteps of v1.10, we have further integrated with Erlang’s new logger by adding four new log levels: notice, critical, alert, and emergency, matching all log levels found in the Syslog standard. The Logger module now supports structured logging by passing maps and keyword lists to its various functions. It is also possible to specify the log level per module, via the Logger.put_module_level/2 function. Log levels per application will be added in future releases.

Elixir v1.11 released - The Elixir programming language - elixir-lang.org

1.11에 추가됐다. 1.19rc가 나온 지금 한참 전에 추가된 피처다. 1.10 버전을 엄청나게 오래 써서 그런지 여기에 멈춰있었다.

/etc/sudoers 파일에 특정 유저가 root 권한을 얻어 실행할 수 있는 동작을 정의할 수 있다. Drop-in을 지원하니 /etc/sudoers 파일을 직접 수정하지 말고 /etc/sudoers.d/deployuser-systemctl 처럼 파일을 만든다.

sudo visudo -f /etc/sudoers.d/deployuser-systemctl

sudoers 파일 문법 검사를 해주는 visudo 를 통해 수정한다.

deployuser ALL=NOPASSWD: /usr/bin/systemctl restart myapp, /usr/bin/systemctl start myapp, /usr/bin/systemctl stop myapp

이제 deployuser 가 myapp 을 비밀번호 입력 없이 sudo systemctl로 컨트롤할 수 있게 했다.

로거의 디폴트 핸들러는 하나만 설치할 수 있다.

config :logger, :default_handler,
  config: [
    type: :file,
    file: ~c"logs/app.log",
    max_no_bytes: 10_000_000,
    max_no_files: 5,
    file_check: 5000,
    filesync_repeat_interval: 5000
  ]

즉, 이렇게 세팅하면 콘솔 출력 로거는 사라지고 파일로만 로그가 남는다. 디폴트 핸들러는 그대로 놔두고 파일 로거를 추가해보자.

config :app, :logger, [
  {:handler, :file_log, :logger_std_h,
   %{
     config: %{
       type: :file,
       file: ~c"logs/app.log",
       max_no_bytes: 10_000_000,
       max_no_files: 5,
       file_check: 5000,
       filesync_repeat_interval: 5000
     },
     level: :info,
     formatter:
     Logger.Formatter.new(
       format: "$date $time [$level] $metadata$message\n"
     )
   }}
]

config 파일에 파일 로거 핸들러를 추가한다. elixir 구조체를 보기 좋게 하려면 Logger.Formatter 를 formatter로 세팅한다. 핸들러를 정의했으니 추가할 차례다.

Logger.add_handlers(:app)

Application.start/2 콜백에서 정의한 로거 파일 핸들러를 추가한다.

erlang에서 검증된 로거 라이브러리를 사용할 수 있게 됐다. 설정 방법은 부자연스럽다. config 파일 수정 하나로 끝났으면 좋겠는데, 핸들러 정의까지만 가능하다. 핸들러 추가 함수를 따로 호출해 줘야 한다. 핸들러 이름을 명시해서 추가하는 방식이 아니라 config 파일에 Application 이름으로 정의한 핸들러를 통째로 추가하는 방식도 어색하다.

config :logger, :console,
  level: :error,
  format: "$time $message $metadata"

elixir 1.15부터 logger backend는 사용 중단 예정(soft-deprecate)이라 default_handler 와 default_formatter 로 설정하는 걸 권장한다.

This release also soft-deprecates Elixir’s Logger Backends in favor of Erlang’s Logger handlers. Elixir will automatically convert your :console backend configuration into the new configuration.

Elixir v1.15 released - The Elixir programming language - elixir-lang.org

왜? erlang logger handler를 사용하기 위해서다. elixir 1.11부터 시작한 erlang logger 통합이 마무리되는 느낌이다.

logger backend에 했던 설정을 default_formatter, default_handler 에 나눠서 하면 된다.

config :logger, :default_handler,
  level: :error

config :logger, :default_formatter,
  format: "$time $message $metadata"

포맷은 default_formatter 옵션에 하고 포맷 외 설정은 default_handler 옵션에 한다. erlang의 logger_std_h를 default handler로 사용한다. standard io 출력이 디폴트라서 다른 설정을 안 하는 한 기존의 console backend라고 생각해도 된다.

If you want to use the previous :console implementation based on Logger Backends, you can still set backends: [Logger.Backends.Console] and place the configuration under config :logger, Logger.Backends.Console. Although consider using the :logger_backends project in such cases, as Logger.Backends.Console itself will be deprecated in future releases

Elixir v1.15 released - The Elixir programming language - elixir-lang.org

logger backends를 써야만 하는 상황이라면 elixir-lang/logger_backends - github.com 라이브러리를 사용하면 된다. 퇴로도 열어준다. 친절하다.

링크

• elixir-lang/logger_backends - github.com(archive)
• logger_std_h — kernel v10.3 - erlang.org(archive)
• Elixir v1.15 released - The Elixir programming language - elixir-lang.org(archive)
• Elixir v1.11 released - The Elixir programming language - elixir-lang.org(archive)

간단히 우회하기로 했다. 실패한 테스트를 한 번 더 돌리는 것이다.

mix test || true
mix test --failed

이렇게 하면 Flaky test(깨지기 쉬운 테스트)가 통과될 수 있는 사이드 이팩트가 있다. 실패한 테스트를 한 번 더 돌려서 통과되는 건 대수롭지 않다. 언젠가는 실패한 테스트를 다시 돌릴 때도 실패하게 될 것이고 그때 확인해서 고치면 된다.

좀 더 나은 방법이 있을 텐데, 지금은 이렇게 깨진 테스트를 편하게 확인하고 있다. Test Reporter GitHub 액션을 사용해도 되지만 아직은 텍스트로 출력하는 게 편하다. 로컬 테스트도 그렇고.

/etc/systemd/system/tbot800.service 파일에 프로그램 실행 정보를 설정한다.

[Unit]
Description=Tbot-800
After=network.target
StartLimitIntervalSec=0

[Service]
Type=simple
Restart=always
RestartSec=1
User=ubuntu

Environment="ACCOUNT1_INTERVAL_MINUTE=60"
Environment="ACCOUNT2_INTERVAL_MINUTE=60"
# ...

ExecStart=/home/ubuntu/app/bin/tbot800 start

[Install]
WantedBy=multi-user.target

이제 systemctl 프로그램을 실행해서 설정을 로딩하고 재부팅해도 자동으로 시작하게 활성화한다. 그리고 바로 시작한다.

$ sudo systemctl daemon-reload
$ sudo systemctl enable tbot800.service
$ sudo systemctl start tbot800.service

프로그램이 잘 실행되고 있는지 로그를 확인해 보자. journalctl 프로그램을 실행한다.

$ journalctl -u tbot800 -f

tbot800[4530]: 13:30:33.648 [info] ########################################
tbot800[4530]: 13:30:33.649 [info] tweet items url: ...
tbot800[4530]: 13:30:33.649 [info] tweet items url: ...
tbot800[4530]: 13:30:33.649 [info] ########################################
tbot800[4530]: 13:30:34.411 [info] shuffle: 535 tweets
tbot800[4530]: 13:30:35.059 [info] shuffle: 626 tweets

잘 나온다. 로그를 얼마나 저장할까?

$ cat /etc/systemd/journald.conf

[Journal]
Storage=persistent  # 로그를 영구적으로 저장 (기본값: auto)
SystemMaxUse=500M   # 최대 저장 용량 지정 (500MB)
SystemKeepFree=1G   # 최소 남길 여유 공간 (1GB)
MaxRetentionSec=7day # 로그를 7일간 보관

/etc/systemd/journald.conf 파일로 설정할 수 있다. Linux 인스턴스 사정에 맞게 용량을 조정한다.

systemd 로 프로세스를 시작하고 systemd-journald 로 로그를 본다. 좋은 디폴트 옵션이다.

서비스 컨테이너(service container)를 사용하면 도커(docker) 컨테이너를 손쉽게 띄울 수 있다. 아래는 서비스 컨테이너로 postgresql을 실행하는 workflow다. ’Creating PostgreSQL service containers - GitHub Docs - docs.github.com’ 글을 참고했다.

jobs:
  test:
    services:
      db:
        image: postgres:12
        ports: ['5432:5432']
        env:
          POSTGRES_PASSWORD: postgres
          options: >-
            --health-cmd pg_isready
            --health-interval 10s
            --health-timeout 5s
            --health-retries 5

애플리케이션에 database 정보를 전달해야 한다. 전달 방법으로 환경 변수를 선택했다.

env:
  DATABASE_NAME: mydb
  DATABASE_USERNAME: postgres
  DATABASE_HOSTNAME: localhost
  DATABASE_PASSWORD: postgres
  DATABASE_PORT: 5432

localhost 가 호스트 이름이다.

database 관련 설정을 모두 환경 변수로 정의했다. 애플리케이션에서는 이 환경 변수를 읽어서 애플리케이션에서 사용할 database 저장소 설정을 하면 된다.

config :awesome_app, AwesomeApp.Repo,
  database: System.get_env("DATABASE_NAME"),
  username: System.get_env("DATABASE_USERNAME"),
  password: System.get_env("DATABASE_PASSWORD"),
  hostname: System.get_env("DATABASE_HOSTNAME"),
  port: System.get_env("DATABASE_PORT", "5432")

서비스 컨테이너 최고다. workflow에 필요한 도커 컨테이너를 손쉽게 실행할 수 있다.

for id <- 100..900, id not in all_rain_ids do
    record = %{"dt" => now_unix, "weather" => [%{"id" => id}]}

    assert {:ok, [weather_struct]} = ResponseParser.parse_response(%{"list" => [record]})
    assert weather_struct.rain? == false, "Expected weather id (#{id}) to NOT be a rain condition"
end

100..900 |> Enum.filter() |> Enum.each() 구문을 한 번에 표현했다. :into, :uniq, :reduce 옵션도 제공해서 말 그대로 포괄 구문으로 웬만한 건 다 표현할 수 있다. 이 정도는 되어야 달달한 문법(Syntactic sugar, 편의 문법)으로 한 자리를 차지할 수 있다.

쓴다면 과용할 것 같고 그냥 무시하자니 간결하게 표현할 수 있는 자리가 분명히 있을 그런 구문이다.

erlang 26.2.5.3
elixir 1.16.3-otp-26

변경 사항이 생기면 자동으로 테스트를 돌리는 데 사용하는 GitHub Action에서 asdf를 사용하지 못한다. 그래서 아래와 같이 버전을 똑같이 수동으로 맞춰서 사용하고 있었다.

strategy:
  # Specify the OTP and Elixir versions to use when building
  # and running the workflow steps.
  matrix:
    otp: ['26.2.5.3']       # Define the OTP version [required]
    elixir: ['1.16.3']    # Define the elixir version [required]
steps:
  # Step: Setup Elixir + Erlang image as the base.
  - name: Set up Elixir
    uses: erlef/setup-beam@v1
    with:
      otp-version: $
      elixir-version: $

asdf는 사용하지 못하지만 .tool-versions 파일은 사용할 수 있다는 걸 최근에 알았다.

# Step: Setup Elixir + Erlang image as the base.
- name: Set up Elixir
  uses: erlef/setup-beam@v1
  with:
    version-file: .tool-versions
    version-type: strict

이제 erlang, elixir 버전을 .tool-versions 한 곳에서만 관리하면 된다.

관련 커밋 da81b1f93f4