Eyeeshot BloG

Mac wifi 비번 확인하기

eyeeshot — Fri, 14 Apr 2023 11:41:47 +0900

security find-generic-password -ga <SSID> | grep password

깨끗한 코드

eyeeshot — Mon, 22 Aug 2022 19:01:59 +0900

나쁜 코드

80년대 후반 킬러 앱 하나를 구현한 회사가 있었다. 제품은 커다란 인기를 얻으며 수많은 전문가가 구매해 사용했다. 그런데 제품 출시 주기가 점점 늘어지다고 프로그램의 시동 시간도 길어지고 프로그램이 죽는 횟수도 늘어나다 사용자가 줄어들어 결국 회사가 망했다. 20여년 지난 후 그 회사 초창기 직원을 우연히 만나 물어보니 원인은 출시가 바빠 코드를 마구 짰고, 기능을 추가할 수록 코드는 엉망이 되었고 결국 감당이 불가능한 수준에 이르러 회사가 망하게 된 것이다. 프로그래머라면 누구나 나쁜 코드로 고생하거나 나쁜코드 를 생성해본 적이 있을 것이다. 우리는 나쁜 코드를 생성하고 나중에 꼭 손보겠다고 생각한다. 또한 돌아간다는 사실에 안도감을 느끼며 안돌아 가는 프로그램보다 돌아가는 쓰레기 좋다고 스스로를 위로 한 경험도 있을 것이다. 우리는 르블랑의 법칙을 몰랐다. 나중은 결코 오지 않는다.

나쁜 코드로 치르는 대가

나쁜 코드는 개발 속도를 크게 떨어뜨린다. 나쁜 코드가 쌓일수록 팀 생산성은 떨어진다. 마침내 0에 근접한다. 생산성이 떨어지면 관리층은 복구를 시도한다. 인력추가로. 하지만 새 인력은 생산성을 높여야 한다는 압박에 나쁜 코드를 더 많이 양산한다. 그래서 더더욱 떨어져 거의 0이 된다.

원대한 재설계의 꿈

나쁜 코드가 많은 코드로 더 이상 일하지 못하는 상태가 재설계를 하게 된다. 새로운 타이거 팀이 구성되고 새로운 프로젝트이기 때문에 유능하고 똑똑한 사람의 지원을 넣고 나머지는 계속해서 시스템을 유지보수 한다. 타이거 팀은 운영에서 변경되는 부분을 합쳐 새 시스템을 만들어야 되기 때문에 최고 10년 걸리는 경우도 보았다고 한다. 결국 새로운 팀이 새로운 재설계를 들어가도 기존 시스템 기능 + 신규 기능까지 하려면 계속적으로 시간이 소모된다. 결국 코드를 작성할 때마다 깨끗한 코드를 만드는 노력이 비용을 절감하는 방법.

태도

간단한 업무라고 예상한 업무가 몇 주동안 늘어진 경험이 있는가? 한줄만 고치면 될 거라 예상했지만 나쁜 코드로 인하여 결국 많은 코드를 수정하는 경험들을 보통 한다. 나쁜 코드는 왜 생길까? 여러가지 이유가 있지만 결국 나쁜 코드를 만드는 것도 코드를 작성하는 본인이 되는 경우가 많다. 어느 환자가 수술 전에 손을 씻지 말라고 요구한다. 시간이 너무 걸리니까 확실히 환자는 상사다 하지만 의사는 단호하게 거부한다. 이유는 질병과 감염의 위험은 환자보다 의사가 더 잘 아니까. 환자 말을 그대로 따르는 행동은 전문가 답지 못하다. 좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다.

원초적 난제

나쁜 코드는 업무속도를 낮춘다. 그런데 모든 프로그래머가 기한을 맞추려면 나쁜 코드를 양산할 수밖에 없다고 느낀다. 나쁜 코드를 양산하면 기한을 맞추지 못한다. 기한을 맞추는 유일한 방법은 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.

깨끗한 코드라는 예술?

꺠끗한 코드를 어떻게 작성할까? 그림을 그리는 행위와 비슷, 청결이라는 힘겹게 습득한 감각을 활용해 자잘한 기법들을 적용하는 절제와 규율이 필요.

깨끗한 코드란?

비야네 스트롭스트룹 ( C++ 창시자이자 The C++ Programming Language 저자)

비야네는 우아하고 효율적인 코드를 좋아한다. 깨끗한 코드는 보는 사람에게 즐거움을 선사해야 한다. 나쁜 코드는 나쁜 코드를 유혹한다. 세세한 사항까지 꼼꼼하게 신경 쓰라. 깨끗한 코드는 한가지에 집중한다. 주변 상황에 현혹되거나 오염되지 않는 채 한길만 걷는다.

그래디 부치 (Object Oriented Analysis and Design with Application 저자)

깨끗한 코드는 단순하고 직접적이다. 깨끗한 코드는 잘 쓴 문장처럼 읽힌다. 깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다. 코드는 추측이 아니라 사실에 기반해야 한다.

‘큰(Big)’ 데이브 토마스 (OTI 창립자이자 이클립스 전략의 대부)

깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다. 깨끗한 코드에는 의미 있는 이름이 붙는다. 특정 목적을 달성하는 방법은 하나만 제공한다. 의존성은 최소이며 각 의존성을 명확히 정의한다. 테스트 케이스가 없는 코드는 깨끗한 코드가 아니다.

마이클 페더스 (Working Effectively with Legacy Code 저자)

깨끗한 코드의 특징은 모두를 아우르는 특징이 하나 있다. 고치려고 살펴봐도 딱히 손 댈 곳이 없다. 깨끗한 코드는 주의 깊게 작성한 코드.

론 제프리스 (Extreme Programming Intalled 와 Extreme Programming Adventure in C# 저자)

중복을 피하라. 한 기능만 수행하라. 제대로 표현하라. 작게 추상화하라.

워드 커닝햄 (위키 창시자, 피트 창시자, 익스트림 프로그래밍 공동 창시자)

코드가 그 문제를 풀기 위한 언어처럼 보인다면 아름다운 코드라 불러도 되겠다. 깨끗한 코드는 읽으면서 놀 날 일이 없어야 한다.

우리는 저자다

Javadoc 에서 @author 필드는 저자를 소개한다. 코드를 작성할 때는 자신이 저자라는 사실을 기억해야한다.

보이스카우트 규칙

시간이 지나도 언제나 깨끗하게 유지해야 한다. 시간이 지날수록 코드가 좋아지는 프로젝트에서 작업한다고 상상해봐라.

프리퀄과 원칙

SRP (The Single Reponsibility Principle) : 단일 책임의 원칙 클래스에는 한 가지, 단 한 가지 변경 이유만 존재해야 한다. OCP (The Open Closed Principle) : 개방 폐쇄의 원칙 클래스는 확장에 열려있어야하며, 변경에 닫혀있어야 한다. LSP (The Liskov Substitution Principle) : 리스코프의 치환 법칙 상속받은 클래스는 기초 클래스를 대체할 수 있어야 한다. DIP (The Dependency Inversion Principle) : 의존 역전의 법칙 추상화에 의존해야하며, 구체화에 의존하면 안된다. ISP (The Interface Segregation Principle) : 인터페이스 분리 원칙 클라이언트에 밀접하게 작게 쪼개진 인터페이스를 유지한다.

작심 3일

eyeeshot — Thu, 12 May 2022 12:10:36 +0900

항상 블로그를 써야지 써야지하면서 결국 몇일 못가고 또 이렇게 되는듯하다.

계속적으로 기억을 남기는 방법은 어딘가에 정리해 놓는 습관인데....

업무를 하며 업무에 관련된 부분은 회사 wiki 에 정리하는 습관은 있는데 재사용을 위한 내 개인적인 기록은 또 2년동안 거의 없는듯하다.

하려고했던 토이프로젝트는 벌써 3~4년이 되어가고... 다시또 조금한것이라도 정리를 계속 해보려고 노력해봐야겠다.

이글이 또 1~2년후에 저때 또 객기부렸구나가 아니라 좀더 변화된 모습의 글로 비추어지도록 노력해봐야곘다.

이글은 그냥 앞으로다 다시한번의 다짐이다.

Python Docker Image Create

eyeeshot — Fri, 29 Jan 2021 11:54:14 +0900

새로운 python 어플리케이션을 구동하기 위해서 항상 관련 라이브어리를 설치하고 설정하고 하는것은 비효율적이다.

Docker는 어플리케이션을 신속하게 구축, 테스트 및 배포할수 있는 소프트웨어 플랫폼이다.

python 을 테스트 및 개발하기위해 docker를 활용하여 생성해 보겠다.

우선 docker를 사용하기 위해서는 Docker를 설치 해야한다.

환경별로 docker 설치방법은 링크 에서 확인하고 설치하면 된다.

docker가 설치 되어있으면 아래 명령어를 실행시키면 docker image를 docker hub에서 받아서 실행시킨다.

$ docker run -it python:3

명령어를 실행하면 local에 image가 없기때문에 hub에서 다운받게 된다. 버전을 따로 기입안했기때문에 lastest로 받게됩니다.

이미지가 이미 있을경우는 위 그림처럼 바로 실행이 된다.

$ docker run -it python:3 bash

#결과

root@c0f596673d25:/#

위명령어를 치면 python 이미지의 터널링으로 접속할수 있다.

환경변수를 넣는 방법이다.

$ docker run -it --env CONF_PATH=eyeeshot python:3 bash

#bash 후 확인.
root@c0f596673d25:/# echo $CONF_PATH
eyeeshot
root@c0f596673d25:/#

디렉터리 연결 방법

$ ls ./sample
requirements.txt  test.py

#결과
$ docker run -it --volume `pwd`/sample:/sample python:3 bash
root@ee20e3d16632:/# ls /sample
requirements.txt  test.py
root@ee20e3d16632:/#

docker 실행 하는 위치에서 sample 폴더를 만든후 그안에 requirements.txt 와 test.py 생성한후 연결해보면 이미지 안에도 같은 파일이 확인되는것을 볼수 있다.

위와같이 python 어플리케이션 실행시 필요한 의존 패키지와 파일들을 연결하여 docker image로 테스트 해볼수 있다.

하지만 항상 저렇게 명령어를 다 붙여서 하는것 비효율 적이다. 따라서 Dockerfile을 작성하여 만들면 편하게 사용할수 있다.

Dockerfile

FROM python:3.8-alpine
LABEL maintainer="eyeeshot@gmail.com"

WORKDIR /app

ADD ./sample /app/
RUN pip install -r requirements.txt

CMD ["python","app.py"]

위 도커 파일을 만든후 아래 명령어를 실행하면 이미지가 생성된다.

$ docker build -t my-python .
$ docker images
REPOSITORY                    TAG                 IMAGE ID            CREATED             SIZE
my-python                     latest              e1adc20df7cb        5 seconds ago       903MB

위와 같이하면 images가 생성된것을 볼수 있을것이다.

$ docker run -d -p 8000:5000 my-python

위 명령어를치면 docker가 정상적으로 뜬것을 확인할수 있다.

#
$ curl localhost:8000
Hello, world! $

curl 로 정상적으로 flask가 동작하는것을 확인할수 있다.

해당소스는 아래 git에서 받을수 있습니다.

github.com/eyeeshot/flask-docker

심볼릭 링크

eyeeshot — Fri, 29 Jan 2021 10:07:31 +0900

심볼릭 링크(symbolic link) 란?

다른 폴더에 있는 파일을 해당 디렉토리에서 사용하는 것과 같은 효과를 내는 링크이다. 윈도우의 바로가기와 비슷한 개념
폴더나 파일 둘다 사용 가능하다.

ln -s [대상 원본 파일] [새로 만들 파일 이름]
 
#예제 volume1/docker 에 있는것을 현제위치에 docker로 심볼릭링크
ln -s /volume1/docker/ docker

AWS IoT Core Job

eyeeshot — Wed, 27 Jan 2021 16:54:27 +0900

1. AWS IoT Jobs 란?
2. AWS IoT Jobs 전제조건.
3. Jobs 디바이스와 작업.
4. 작업 생성

1. AWS IoT Jobs 란?

AWS IoT 작업 서비스는 AWS IoT에 연결되는 하나 이상의 디바이스로 전송된 후 실행되는 원격 작업 세트를 정의하는 데 사용.
주된 목적은 소프트웨어 또는 펌웨어 업데이트를 디바이스에게 알리는데 사용.
작업 문서란 AWS IoT Job 생성시 대상이 되는 디바이스로 전송되는 문서.

2. AWS IoT Jobs 전제조건

작업을 생성시 작업문서는 Amazon S3 버킷의 파일 링크 또는 생성시 본문에 입력할수 있습니다.
AWS 계정에 속한 사물 및 사물 그룹이 대상이 됩니다. 따라서 사물 및 사물 그룹이 있어야합니다.
작업 생성을 위해 IAM 권한 필요

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:ListAllMyBuckets",
        "s3:CreateBucket",
        "s3:PutBucketVersioning",
        "s3:GetBucketLocation",
        "s3:GetObjectVersion",
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucketVersions"
      ],
      "Resource": [
        "arn:aws:s3:::{{RESOURCE}}",
        "arn:aws:s3:::us-east-1-greengrass-updates/*",
        "arn:aws:s3:::us-west-2-greengrass-updates/*",
        "arn:aws:s3:::ap-northeast-1-greengrass-updates/*",
        "arn:aws:s3:::ap-northeast-2-greengrass-updates/*",
        "arn:aws:s3:::ap-southeast-2-greengrass-updates/*",
        "arn:aws:s3:::eu-central-1-greengrass-updates/*",
        "arn:aws:s3:::eu-west-1-greengrass-updates/*"
      ]
    },
    {
      "Action": [
        "greengrass:CreateSoftwareUpdateJob"
      ],
      "Effect": "Allow",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "iot:*",
        "iam:GetRole",
        "iam:PassRole",
        "iam:ListRoles",
        "signer:GetSigningProfile",
        "signer:StartSigningJob",
        "signer:DescribeSigningJob"
      ],
      "Resource": "*"
    }
  ]
}

3. AWS IoT Jobs 디바이스와 작업

작업을 생성하기전 디바이스는 AWS IoT Core에 연결되어있어야 한다.
작업을 실행하기할 대상 디바이스는 프로그래밍을 사전에 준비해야 한다.
대상이 되는 디바이스는 아래의 토픽을 구독하고 있어야합니다.
- $aws/things/{디바이스이름}/jobs/notify(또는 $aws/things/{디바이스이름}/jobs/notify-next)
- $aws/things/{디바이스이름}/jobs/get/accepted
- $aws/things/{디바이스이름}/jobs/get/rejected
- $aws/things/{디바이스이름}/jobs/{jobId}/get/accepted
- $aws/things/{디바이스이름}/jobs/{jobId}/get/rejected
디바이스 워크 플로우는 크게 두가지로 나눠질수 있다.

Get the next Job
1. 다비아스가 처음 온라인에 연결되면 해당 디바이스의 notify-next 토픽을 구독해야합니다.
2. $aws/things/{디바이스이름}/jobs/{작업ID}/get 토픽에 메시지를 게시합니다.
3. $next에 저장된 모든 상태를 포함하여 다음 작업, 작업 문서 및 기타 세부 정보를 가져옵니다.statusDetails 작업 문서에 코드 파일 서명이 있는 경우 작업 요청을 진행하기 전에 서명을 확인해야 합니다.
4. $aws/things/{디바이스이름}/jobs/{작업ID}/update 토픽에 메시지를 게시합니다. 또는 이번 단계와 이전 단계를 단일 호출로 결합하고 싶다면 디바이스에서 $aws/things/{디바이스이름}/jobs/start-next 토픽에 메시지를 게시하셔도 좋습니다.
5. (선택 사항) $aws/things/{디바이스이름}/jobs/{작업ID}/update 또는 $aws/things/{디바이스이름}/jobs/start-next 를 호출하면 stepTimeoutInMinutes에 대한 값을 설정하여 단계 타이머를 추가할 수 있습니다.
6. 작업 진행 상황이 변화될때마다 상태를 변경하려면 $aws/things/{디바이스이름}/jobs/{작업ID}/update 토픽에 메시지를 게시합니다.
7. $aws/things/{디바이스이름}/jobs/{작업ID}/get 토픽에 메시지를 게시하면서 작업 실행을 계속 모니터링합니다. 작업 실행이 삭제되면 ResourceNotFoundException를 반환합니다.
8. 작업이 완료되면 $aws/things/{디바이스이름}/jobs/{작업ID}/update 토픽에 메시지를 게시하여 작업 상태를 업데이트하고 성공 또는 실패 여부를 보고합니다.
9. 이번 작업의 실행 상태는 종료 상태로 바뀌었기 때문에 다음에 실행할 수 있는 작업(있는 경우)도 바뀝니다. 그러고 나서 디바이스에게도 다음 대기 중인 작업 실행이 바뀌었다는 알림 메시지가 수신됩니다. 이때는 디바이스가 2번으로에서 설명한 대로 계속 진행되어야 합니다.
Pick from available jobs
1. 디바이스가 처음 온라인에 연결되면 해당 사물의 notify 주제를 구독해야 합니다.
2. $aws/things/{디바이스이름}/jobs/get 토픽에 메시지를 게시하여 대기 중인 작업 실행 목록을 가져옵니다.
3. 목록에 작업 실행이 다수인 경우에는 하나를 선택합니다.
4. $aws/things/{디바이스이름}/jobs/{작업ID}/get 토픽에 메시지를 게시합니다. statusDetails 작업 문서에 코드 파일 서명이 있는 경우 작업 요청을 진행하기 전에 서명을 확인해야 합니다.
5. $aws/things/{디바이스이름}/jobs/{작업ID}/update 토픽에 메시지를 게시합니다. 이 명령에서 includeJobDocument 필드가 true로 설정되어 있으면 디바이스가 이전 단계를 건너뛰고 이번 단계에서 작업 문서를 가져올 수 있습니다.
6. 선택적으로, $aws/things/{디바이스이름}/jobs/{작업ID}/update 토픽에 메시지를 게시하면 stepTimeoutInMinutes에 대한 값을 설정하여 단계 타이머를 추가할 수 있습니다.
7. 작업 진행 상황이 변화될때마다 상태를 변경하려면 $aws/things/{디바이스이름}/jobs/{작업ID}/update 토픽에 메시지를 게시합니다.
8. $aws/things/{디바이스이름}/jobs/{작업ID}/get 토픽에 메시지를 게시하면서 작업 실행을 계속 모니터링합니다. 작업 실행이 삭제되면 ResourceNotFoundException를 반환합니다.
9. 작업이 완료되면 $aws/things/{디바이스이름}/jobs/{작업ID}/update 토픽에 메시지를 게시하여 작업 상태를 업데이트하고 성공 또는 실패 여부를 보고합니다.
10. 이번 작업의 실행 상태는 종료 상태로 바뀌었기 때문에 다음에 실행할 수 있는 작업(있는 경우)도 바뀝니다. 그러고 나서 디바이스에게도 다음 대기 중인 작업 실행이 바뀌었다는 알림 메시지가 수신됩니다. 이때는 디바이스가 2번으로에서 설명한 대로 계속 진행되어야 합니다.

디바이스에서 AWS IoT로 MQTT 통신 예제

게시할 토픽	내용	요청 payload example
$aws/things/{디바이스이름}/jobs/{작업ID}/get	clientToken : 선택 사항입니다. 요청과 응답의 연관성을 나타낼때 사용하는 클라이언트 토큰입니다. 여기에 임의 값을 입력하면 응답에 반영됩니다.	`{ "clientToken": "string" }`
$aws/things/{디바이스이름}/jobs/{작업ID}/update	status : 새로운 작업 실행 상태(IN_PROGRESS, FAILED, SUCCEEDED 또는 REJECTED) 이 명령은 업데이트 할 때 마다 지정해야 합니다. statusDetails : 작업 실행 상태를 설명하는 이름-값 페어의 모음입니다. 지정하지 않으면 statusDetails가 바뀌지않습니다. expectedVersio : 예상되는 현재 작업 실행 버전입니다. 작업 실행은 업데이트할 때마다 버전이 일정하게 증가합니다. AWS IoT 작업 서비스에 저장된 작업 실행 버전이 일치하지 않으면 VersionMismatch 오류와 함께 업데이트가 거부되고, 현재 작업 실행 상태에 대한 데이터가 포함된 ErrorResponse 반환됩니다. executionNumber : 선택 사항입니다. 디바이스에서 작업 실행을 식별하기 위한 숫자입니다. 지정하지 않으면 최신 작업 실행이 사용됩니다. includeJobExecutionState : 선택 사항입니다. 이 명령을 추가하여 true로 설정하면 응답에 JobExecutionState 필드가 포함됩니다. 기본값은 false입니다. includeJobDocument : 선택 사항입니다. 이 명령을 추가하여 true로 설정하면 응답에 JobDocument가 포함됩니다. 기본값은 false입니다. stepTimeoutInMinutes : 이 디바이스가 이 작업 실행을 마쳐야 하는 시간을 지정합니다. 이 타이머가 완료하기 전에 또는 타이머가 재설정되면(UpdateJobExecution를 다시 호출하고, 상태를 IN_PROGRESS로 설정하고, 이 필드에 새 제한 시간 값을 지정하여) 작업 실행 상태는 TIMED_OUT로 설정됩니다. 이 제한 시간을 설정 또는 재설정해도 작업이 생성되었을 때 지정했을 수도 있는 작업 실행 제한 시간에는 영향을 주지 않습니다(CreateJob와 함께 timeoutConfig 사용). clientToken : 요청과 응답의 연관성을 나타낼 때 사용하는 클라이언트 토큰입니다. 여기에 임의 값을 입력하면 응답에 반영됩니다.	`{ "status": "job-execution-state", "statusDetails": { "string": "string" ... }, "expectedVersion": "number", "executionNumber": long, "includeJobExecutionState": boolean, "includeJobDocument": boolean, "stepTimeoutInMinutes": long, "clientToken": "string" }`
$aws/things/{디바이스이름}/jobs/start-next	statusDetails : 작업 실행 상태를 설명하는 이름-값 페어의 모음입니다. 지정하지 않으면 statusDetails가 바뀌지 않습니다. stepTimeOutInMinutes : 이 디바이스가 이 작업 실행을 마쳐야 하는 시간을 지정합니다. 이 타이머가 완료하기 전에 또는 타이머가 재설정되면(UpdateJobExecution를 호출하고, 상태를 IN_PROGRESS에 설정하고, 새로운 제한 시간 값을 필드 stepTimeoutInMinutes에 지정하여) 작업 실행 상태는 TIMED_OUT로 설정됩니다. 이 제한 시간을 설정해도 작업이 생성될 때 지정했을 수도 있는 작업 실행 제한 시간에는 영향을 주지 않습니다(CreateJob 필드를 사용하는 timeoutConfig). clientToken : 메시지 브로커는 특정 구독 없이 $aws/things/{디바이스이름}/jobs/start-next/accepted 및 $aws/things/{디바이스이름}/jobs/start-next/rejected를 게시합니다.	`{ "statusDetails": { "string": "job-execution-state" ... }, "stepTimeoutInMinutes": long, "clientToken": "string" }`

AWS IoT 에서 디바이스로 MQTT 통신 예제

구독할 토픽	내용	응답 payload example
$aws/things/{디바이스이름}/jobs/notify	대기 중인 사물의 작업 실행 목록에 작업이 추가되거나 제거되었을 때 혹은 목록의 첫 번째 작업 실행이 바뀌었을때 대상 디바이스에게 토픽으로 메시지 게시합니다.	`{ "timestamp" : 10011, "jobs" : { "IN_PROGRESS" : [ { "jobId" : "other-job", "queuedAt" : 10003, "lastUpdatedAt" : 10009, "executionNumber" : 1, "versionNumber" : 1 } ], "QUEUED" : [ { "jobId" : "this-job", "queuedAt" : 10011, "lastUpdatedAt" : 10011, "executionNumber" : 1, "versionNumber" : 0 } ] } }`
$aws/things/{디바이스이름}/jobs/notify-next	대기 중인 사물의 작업 실행 목록에 작업이 추가되거나 제거되었을 때 혹은 목록의 첫 번째 작업 실행이 바뀌었을때 대상 디바이스에게 토픽으로 메시지 게시합니다.	`{ "timestamp" : 10011, "execution" : { "jobId" : "other-job", "status" : "IN_PROGRESS", "queuedAt" : 10009, "lastUpdatedAt" : 10009, "versionNumber" : 1, "executionNumber" : 1, "jobDocument" : {"c":"d"} } }`
$aws/things/{디바이스이름}/jobs/get/accepted	$aws/things/{디바이스이름}/jobs/get 토픽에 메시지를 게시하면 종료 상태가 아닌 사물의 모든 작업 목록을 가져옵니다. inProgressJobs : IN_PROGRESS 상태인 jobs 목록입니다. queuedJobs : QUEUED 상태인 Jobs 목록입니다. clientToken : 요청과 응답의 연관성을 나타낼 때 사용하는 클라이언트 토큰입니다. timestamp : 메시지가 전송된 이후 경과 시간(초) 입니다.	`{ "inProgressJobs" : [ JobExecutionSummary ... ], "queuedJobs" : [ JobExecutionSummary ... ], "timestamp" : 1489096425069, "clientToken" : "client-001" }`
$aws/things/{디바이스이름}/jobs/get/rejected	$aws/things/{디바이스이름}/jobs/get 토픽에 메시지를 게시하면 요청이 잘못된경우 error respone 으로 반환된다 code : InvalidTopic : 요청이 API로 매핑되어 있지 않은 AWS IoT 작업 서비스 네임스페이스의 주제로 전송되었습니다. InvalidJson : 요청 내용이 유효한 UTF-8-인코딩 JSON으로 해석되지 않습니다. InvalidRequest : 요청 내용이 잘못되었습니다. 요청에 잘못된 상태 세부 정보가 포함되어 있으면 이 코드가 반환됩니다. 메시지에는 오류에 대한 세부 정보가 포함됩니다. InvalidStateTransition : 작업 실행의 현재 상태로 인해 작업 실행을 잘못된 상태로 변경하려는 업데이트 시도입니다. (ex: SUCCEEDED 에서 IN_PROGRESS로 변경하려는 시도) 이때는 오류 메시지 본문에 executionState 필드도 포함됩니다. ResourceNotFound : 요청 주제에서 지정한 JobExecution이 존재하지 않습니다. VersionMismatch : 요청에서 지정한 예상 버전이 AWS IoT 작업 서비스의 작업 실행 버전과 일치하지 않습니다. 이때는 오류 메시지 본문에 executionState 필드도 포함됩니다. InternalError : 요청을 처리하는 도중 내부 오류가 발생했습니다. RequestThrottled : 요청에 병목 현상이 발생했습니다. TerminalStateReached : 종료 상태의 작업에서 작업을 설명하는 명령을 실행했을 때 발생합니다. message : 오류메시지 문자열입니다. clientToken : 요청과 응답의 연관성을 나타내는 임의 문자열입니다. timestamp : epoch 이후 경과 시간(초)입니다 executionState : 이 필드는 code 필드에 InvalidStateTransition 또는 VersionMismatch 값이 있을 때만 포함됩니다. 따라서 이러한 경우에는 현재 작업 실행 상태에 대한 데이터를 가져오기 위해 별도의 DescribeJobExecution 요청을 수행할 필요가 없습니다.	`{ "code": "ErrorCode", "message": "string", "clientToken": "string", "timestamp": timestamp, "executionState": JobExecutionState }`
$aws/things/{디바이스이름}/jobs/{jobId}/get/accepted	$aws/things/thingName/jobs/jobId/get 토픽에 메시지를 게시하면 반환되는 내용 execution jobId : 작업 생성 시 할당한 고유 식별자입니다. thingName : 작업을 실행 중인 사물의 이름입니다. jobDocument : 작업 문서의 내용입니다. status : 작업 실행의 상태입니다. 다음 중 하나일 수 있습니다. QUEUED, IN_PROGRESS, FAILED, SUCCEEDED, CANCELED, TIMED_OUT, REJECTED 또는 REMOVED. statusDetails : 작업 실행 상태를 설명하는 이름-값 페어의 모음입니다. queuedAt : 작업 실행이 대기 상태로 전환된 epoch 이후 경과 시간(초)입니다. startedAt : 작업 실행이 시작된 epoch 이후 경과 시간(초)입니다. lastUpdatedAt : 작업 실행이 마지막으로 업데이트된 epoch 이후 경과 시간(초)입니다. versionNumber : 작업 실행 버전입니다. 작업 실행 버전은 디바이스에서 업데이트될 때마다 일정하게 증가합니다. executionNumber : 디바이스에서 작업 실행을 식별하기 위한 숫자입니다. 나중에는 작업 실행 정보를 반환하거나 업데이트하는 명령에 사용할 수 있습니다.	`{ "execution" : { "jobId" : "string", "thingName" : "string", "jobDocument" : "string", "status": "QUEUED\|IN_PROGRESS\|FAILED\|SUCCEEDED\|CANCELED\|TIMED_OUT\|REJECTED\|REMOVED", "statusDetails": { "string": "string" }, "queuedAt" : "timestamp", "startedAt" : "timestamp", "lastUpdatedAt" : "timestamp", "versionNumber" : "number", "executionNumber": long }, "timestamp": "timestamp", "clientToken": "string" }`
$aws/things/{디바이스이름}/jobs/{jobId}/get/rejected	$aws/things/{디바이스이름}/jobs/{작업ID}/update 의 요청이 잘못된경우 error respone 으로 반환된다 code : InvalidTopic : 요청이 API로 매핑되어 있지 않은 AWS IoT 작업 서비스 네임스페이스의 주제로 전송되었습니다. InvalidJson : 요청 내용이 유효한 UTF-8-인코딩 JSON으로 해석되지 않습니다. InvalidRequest : 요청 내용이 잘못되었습니다. 요청에 잘못된 상태 세부 정보가 포함되어 있으면 이 코드가 반환됩니다. 메시지에는 오류에 대한 세부 정보가 포함됩니다. InvalidStateTransition : 작업 실행의 현재 상태로 인해 작업 실행을 잘못된 상태로 변경하려는 업데이트 시도입니다. (ex: SUCCEEDED 에서 IN_PROGRESS로 변경하려는 시도) 이때는 오류 메시지 본문에 executionState 필드도 포함됩니다. ResourceNotFound : 요청 주제에서 지정한 JobExecution이 존재하지 않습니다. VersionMismatch : 요청에서 지정한 예상 버전이 AWS IoT 작업 서비스의 작업 실행 버전과 일치하지 않습니다. 이때는 오류 메시지 본문에 executionState 필드도 포함됩니다. InternalError : 요청을 처리하는 도중 내부 오류가 발생했습니다. RequestThrottled : 요청에 병목 현상이 발생했습니다. TerminalStateReached : 종료 상태의 작업에서 작업을 설명하는 명령을 실행했을 때 발생합니다. message : 오류메시지 문자열입니다. clientToken : 요청과 응답의 연관성을 나타내는 임의 문자열입니다. timestamp : epoch 이후 경과 시간(초)입니다 executionState : 이 필드는 code 필드에 InvalidStateTransition 또는 VersionMismatch 값이 있을 때만 포함됩니다. 따라서 이러한 경우에는 현재 작업 실행 상태에 대한 데이터를 가져오기 위해 별도의 DescribeJobExecution 요청을 수행할 필요가 없습니다.	`{ "code": "ErrorCode", "message": "string", "clientToken": "string", "timestamp": timestamp, "executionState": JobExecutionState }`
$aws/things/thingName/jobs/start-next/accepted	execution jobId : 작업 생성 시 할당한 고유 식별자입니다. thingName : 작업을 실행 중인 사물의 이름입니다. jobDocument : 작업 문서의 내용입니다. status : 작업 실행의 상태입니다. 다음 중 하나일 수 있습니다. QUEUED, IN_PROGRESS, FAILED, SUCCEEDED, CANCELED, TIMED_OUT, REJECTED 또는 REMOVED. statusDetails : 작업 실행 상태를 설명하는 이름-값 페어의 모음입니다. queuedAt : 작업 실행이 대기 상태로 전환된 epoch 이후 경과 시간(초)입니다. startedAt : 작업 실행이 시작된 epoch 이후 경과 시간(초)입니다. lastUpdatedAt : 작업 실행이 마지막으로 업데이트된 epoch 이후 경과 시간(초)입니다. versionNumber : 작업 실행 버전입니다. 작업 실행 버전은 디바이스에서 업데이트될 때마다 일정하게 증가합니다. executionNumber : 디바이스에서 작업 실행을 식별하기 위한 숫자입니다. 나중에는 작업 실행 정보를 반환하거나 업데이트하는 명령에 사용할 수 있습니다.	`{ "execution" : { "jobId" : "022", "thingName" : "MyThing", "jobDocument" : "< contents of job document >", "status" : "IN_PROGRESS", "queuedAt" : 1489096123309, "lastUpdatedAt" : 1489096123309, "versionNumber" : 1, "executionNumber" : 1234567890 }, "clientToken" : "client-1", "timestamp" : 1489088524284, }`
$aws/things/thingName/jobs/start-next/rejected	$aws/things/{디바이스이름}/jobs/start-next 의 요청이 잘못된경우 error respone 으로 반환된다 code : InvalidTopic : 요청이 API로 매핑되어 있지 않은 AWS IoT 작업 서비스 네임스페이스의 주제로 전송되었습니다. InvalidJson : 요청 내용이 유효한 UTF-8-인코딩 JSON으로 해석되지 않습니다. InvalidRequest : 요청 내용이 잘못되었습니다. 요청에 잘못된 상태 세부 정보가 포함되어 있으면 이 코드가 반환됩니다. 메시지에는 오류에 대한 세부 정보가 포함됩니다. InvalidStateTransition : 작업 실행의 현재 상태로 인해 작업 실행을 잘못된 상태로 변경하려는 업데이트 시도입니다. (ex: SUCCEEDED 에서 IN_PROGRESS로 변경하려는 시도) 이때는 오류 메시지 본문에 executionState 필드도 포함됩니다. ResourceNotFound : 요청 주제에서 지정한 JobExecution이 존재하지 않습니다. VersionMismatch : 요청에서 지정한 예상 버전이 AWS IoT 작업 서비스의 작업 실행 버전과 일치하지 않습니다. 이때는 오류 메시지 본문에 executionState 필드도 포함됩니다. InternalError : 요청을 처리하는 도중 내부 오류가 발생했습니다. RequestThrottled : 요청에 병목 현상이 발생했습니다. TerminalStateReached : 종료 상태의 작업에서 작업을 설명하는 명령을 실행했을 때 발생합니다. message : 오류메시지 문자열입니다. clientToken : 요청과 응답의 연관성을 나타내는 임의 문자열입니다. timestamp : epoch 이후 경과 시간(초)입니다 executionState : 이 필드는 code 필드에 InvalidStateTransition 또는 VersionMismatch 값이 있을 때만 포함됩니다. 따라서 이러한 경우에는 현재 작업 실행 상태에 대한 데이터를 가져오기 위해 별도의 DescribeJobExecution 요청을 수행할 필요가 없습니다.	`{ "code": "ErrorCode", "message": "string", "clientToken": "string", "timestamp": timestamp, "executionState": JobExecutionState }`

4. 작업 생성

3번 디바이스의 작업을 할 준비가 되어 있어야한다.
Custom Job
- AWS 코어에서는 작업파일을 추가하기 위해서는 S3에 별도로 업로드 후 그 파일을 선택해야함.
- 작업 문서 : 디바이스가 수행할 원격 작업을 정의한 JSON 문서.
  - 작업을 생성하려면 반드시 작업 문서가 있어야 함.
  - 작업 문서는 S3 버킷에 저장되거나, 작업 생성 요청시 인라인으로 포함될 수 있음.
- Document
  - 작업 생성시 인라인으로 들어갈때 사용하는 Param
- Document Source
  - 작업 생성시 S3 버킷에 저장되어있는 작업문서 위치
- Pre-signed URL : 디바이스가 작업 문서 자체에 포함된 데이터(URL)에 한시적으로 접근할 수 있도록 사용할 수 있는 기능.
  - 보안 향상을 위해 사용할 수 있는 선택적 기능.
  - 대상 데이터(펌웨어 등)는 반드시 S3에 저장된 후 자리 표시자 링크를 작업 문서에 추가하여 사용
    - 이는 Pre-signed URL이 S3의 기능이기 때문.
  - 작업문서의 예약어 aws:iot:s3-presigned-url 이 있는경우 동작.
    ex)
    ${aws:iot:s3-presigned-url:https://s3.amazonaws.com/bucket/key}
- Code Signing : 작업 문서에 반드시 Code-sign용 자리 표시자가 포함되어 있어야 한다.
  - Signing을 위해선 Signing Profile이 생성되어야 한다.
    - Signing Profile을 생성하려면 ACM에 signing용 Certificate가 import 되어 있어야 한다.
  - 작업문서의 예약어 aws:iot:code-sign-signature 가 있는경우 동작
    ex )
    ${aws:iot:code-sign-signature:s3://<region>.<my-s3-bucket>/<my-code-file>@<code-file-version-id>}

Python Docker 이미지 생성 주의점!

eyeeshot — Tue, 26 Jan 2021 11:40:58 +0900

Alpine을 사용하면 Python Docker 빌드 속도가 50 배 더 느려질 수 있습니다.

한줄 정리 하면.

단순히 ubuntu 와 alpine 을 비교했을떄는 alpine이 빌드속도나 이미지 용량이 적지만.

python aplication 을 위한 package 등을 설치할때는 빌드속도나 이미지 용량이 올라간다.

요약 하자면 파이썬 라이브러리들은 보통 Wheel 포맷을 사용하는 데 Alpine 리눅스는 Wheel 포맷을 지원하지 않기 때문에 소스 코드를 내려받아 직접 컴파일해야할 경우가 있기 때문이다.

Base image	Time to build	Image size	Research required
python:3.8-slim	30 seconds	363MB	No
python:3.8-alpine	1557 seconds	851MB	Yes

자세한 사항은 아래 링크를 참고 하면 될것같다.

출처 : pythonspeed.com/articles/alpine-docker-python/

Docker 환경변수 설정

eyeeshot — Mon, 18 Jan 2021 17:44:51 +0900

Docker 환경변수 설정하는방법은 아래와 같이 두가지이다.

1. Param 설정으로 적용하는 방법

docker run -e "ENV=foo" ubuntu /bin/bash

2. env 파일을 만들어 적용하는 방법

docker run --env-file ./.env ubuntu /bin/bash

.env

# 주석!
HOST=1.1.1.1
PATH=/home/eyeeshot

만약 둘다 설정할경우는 --env-file 다음 -e / --env 처리가 됨.

따라서 --env-file 로 적용한 변수를 또 적용할경우 -e 적용한것으로 적용하게됨.

ssh 파일전송 scp

eyeeshot — Mon, 18 Jan 2021 17:00:11 +0900

ssh로 파일을 전송할수 있다.

아래와 같은 방법을 사용하면 된다.

scp {전송할 파일} {id@server IP}:{저장될 경로}
ex) scp ./a.txt eyeeshot@123.123.123.123:/home/file

#포트를 사용할경우
 -p {ssh포트번호} 옵션을 추가
ex) scp -p 1414 ./a.txt eyeeshot@123.123.123.123:/home/file

Git remote url change

eyeeshot — Mon, 18 Jan 2021 16:49:13 +0900

#현재 remote url 확인
git remote -v

#change remote url
git remote set-url origin https://github.com/~~~~~~

#바뀐지 다시 확인
git remote -v