작은 예약 작업에 명확한 경계를 부여하세요.

하나의 유한한 작업 정의

기존 레코드에서 작은 일일 요약을 재구성하는 개인 도구를 상상해 보십시오. 이 작업은 제한된 데이터 세트를 읽고, 대체 요약 하나를 준비하고, 종료합니다. 웹 서버가 아니며 예약된 시작 사이에 계속 실행되어서는 안 됩니다. 타이머를 추가하기 전에 입력, 대상, 예상 소요 시간 및 성공 기준을 기록하십시오.

이 예제는 systemd와 util-linux가 있는 Linux 호스트를 가정합니다 flock, 관리자 액세스, 그리고 기존 비특권 계정과 그룹 이름은 fieldjob. 검토된 작업 스크립트는 다음 위치에 있습니다 /opt/field-jobs/build-summary 이며 포그라운드에서 실행됩니다. 관리자가 해당 스크립트를 소유하며, 작업 계정은 읽고 실행할 수 있지만 코드를 다시 작성할 수는 없습니다. 배포판의 실행 파일 경로를 확인하십시오. 이는 템플릿이며 설치된 OffVPS 예약 서비스가 아닙니다.

스크립트는 0이 아닌 종료 상태로 실패를 보고해야 합니다. 대체 파일의 경우 게시하기 전에 임시 결과를 준비하고 확인하도록 설계하십시오. 데이터베이스 작업의 경우 데이터베이스의 트랜잭션 또는 중복 제거 메커니즘을 사용하십시오. 잠금만으로는 부분적으로 완료된 작업을 반복해도 안전하게 만들 수 없습니다.

시간대와 누락 실행 정책 선택

우리 요약은 UTC 02:15에 하루 한 번 유용합니다. 머신의 로컬 시간대가 보이지 않는 종속성이 되지 않도록 명시적 시간대를 사용하십시오. 이 예제에서 UTC는 계절적 시계 변경을 피합니다. 로컬 민간 시간에 묶인 비즈니스 작업에는 명명된 시간대와 일광 절약 시간 동작 검토가 필요합니다. systemd 시간 참조 는 캘린더 표현식을 설명합니다.

이 템플릿을 다음으로 저장하십시오 /etc/systemd/system/field-summary.timer 이름을 검토한 후 의도한 VPS에서:

[Unit]
Description=Daily personal-tool summary

[Timer]
OnCalendar=*-*-* 02:15:00 UTC
Persistent=true
Unit=field-summary.service

[Install]
WantedBy=timers.target

Persistent=true 는 캘린더 이벤트를 놓친 경우 비활성 기간 후 따라잡기 활성화를 요청합니다. 놓친 각 날짜에 대해 별도의 실행을 재생하지는 않습니다. 또한 타이머는 해당 서비스가 활성 상태인 동안 동일한 서비스의 다른 인스턴스를 시작하지 않습니다. 이러한 동작과 예약 정확성은 다음에 설명되어 있습니다 타이머 참조. 따라잡기를 활성화하기 전에 늦은 요약이 유용한지 결정하십시오.

서비스 사용자, 상태 디렉터리 및 잠금 설정

일치하는 /etc/systemd/system/field-summary.service 는 작업을 설명합니다:

[Unit]
Description=Build the personal-tool summary

[Service]
Type=oneshot
User=fieldjob
Group=fieldjob
WorkingDirectory=/opt/field-jobs
StateDirectory=field-summary
StateDirectoryMode=0700
UMask=0077
ExecStart=/usr/bin/flock --nonblock --conflict-exit-code 75 /var/lib/field-summary/job.lock /opt/field-jobs/build-summary
TimeoutStartSec=5min
StandardOutput=journal
StandardError=journal

Type=oneshot 는 완료되는 명령에 적합합니다. 명시적 시작 시간 제한이 이 예제를 제한합니다. 다음을 추가하지 마십시오 RemainAfterExit=yes 를 각 실행 후 비활성 상태가 되어야 하는 서비스에 추가하지 마십시오. 다음을 참조하십시오 systemd의 서비스 의미. 워크로드에서 시간 제한을 설정하고, 5분이 모든 작업에 맞는다고 가정하기보다 중단을 안전하게 만드십시오.

이 시스템 서비스의 경우, StateDirectory 는 다음 아래에 명명된 디렉터리를 만듭니다 /var/lib 서비스 소유권으로. 작업 디렉터리, 사용자, 권한 및 출력 대상이 명시적입니다. 스크립트는 자체 도구와 데이터에 절대 경로를 사용해야 합니다. 환경 및 디렉터리 규칙은 다음에 문서화되어 있습니다 systemd의 실행 참조. 명령줄 인수에 비밀 값을 넣거나 로그에 기록하지 마십시오.

비차단 flock 래퍼는 다른 협력 호출이 이 잠금을 보유할 때 코드 75로 종료합니다. 우리는 건너뛴 요약을 완료된 작업으로 취급하기보다 검토가 필요한 가시적 실패로 남겨둡니다. 모든 수동 호출은 동일한 래퍼와 잠금 경로를 사용해야 합니다. 실행 중인 작업을 해제하기 위해 잠금 파일을 삭제하지 마십시오. 새 파일은 별도 잠금을 생성할 수 있습니다. 이는 로컬 파일 시스템 패턴이며 VPS 인스턴스 간 분산 잠금이 아닙니다. 다음을 참조하십시오 업스트림 flock 매뉴얼.

파일을 확인한 후 통제된 실행 한 번 시도

첫 실행에는 아웃바운드 이메일, 결제 및 기타 부작용이 비활성화된 일회용 데이터 세트를 사용하십시오. 활성화 전에 테스트 호스트에서 구문 분석된 일정과 유닛 파일을 검사하십시오:

systemd-analyze calendar '*-*-* 02:15:00 UTC'
systemd-analyze verify /etc/systemd/system/field-summary.service /etc/systemd/system/field-summary.timer

이러한 검사는 유닛 및 일정 실수를 잡을 수 있지만, 스크립트가 올바른 요약을 생성한다는 것을 입증하지는 못합니다. systemd-analyze 참조 는 그 범위를 설명합니다. 오류를 수정한 후 검토된 파일을 로드하고 테스트 작업을 명시적으로 시작하십시오:

sudo systemctl daemon-reload &&
  sudo systemctl start field-summary.service
systemctl status field-summary.service --no-pager
sudo journalctl -u field-summary.service --since "10 minutes ago" --no-pager

유한한 성공적 호출과 검증된 출력 아티팩트를 기대하십시오. 성공한 원샷은 이후 비활성으로 표시될 수 있습니다. 빈 입력 동작을 포함하여 결과 자체를 검사하십시오. 테스트 전용 실행을 의도적으로 느리게 만들고, 테스트 데이터셋에 대해 동일한 잠금 명령을 두 번 호출하여 두 번째 호출이 경쟁 결과를 기록하지 않고 잠금 경합을 보고하는지 확인하십시오.

출력을 확인한 후에만 일정 활성화

sudo systemctl enable --now field-summary.timer
systemctl list-timers field-summary.timer --all

다음 예정 시간을 확인한 다음 첫 번째 예약 결과를 검토하십시오. 시작 시간, 종료 시간, 처리된 항목 수 및 결과를 스크립트 로그에 유지하십시오. 성공 기록이 없다는 것은 검사할 이유이지 작업이 실행되었다는 증거가 아닙니다. 다음을 참조하십시오 systemctl의 타이머 및 활성화 명령.

향후 시작을 일시 중지하려면 다음을 사용하십시오 sudo systemctl disable --now field-summary.timer. 이것은 이미 실행 중인 서비스를 종료하지 않습니다. 중단이 필요한 경우 먼저 현재 쓰기를 안전하게 중지할 수 있는지 확인하십시오. 작업이 증가함에 따라 기간, 재시도 및 외부 API 제한을 검토하십시오. 여러 머신에는 공유 조정이 필요합니다. 다음으로 계속하십시오 개인 도구 시나리오 및 복원 연습 이 자동화가 유지 관리하는 데이터를 위해.