반응형

schedule_interval

Airflow에서 Dag들이 실행하는데 정시에 실행이 되지않고 약간의 초가 지난뒤에 실행되는걸 볼수있다.

Run: ... 이 부분을 확인할 것

이유는

with models.DAG(
        MAIN_DAG_ID,
        default_args=default_args,
        schedule_interval='*/30 * * * * *',
        start_date=datetime(2021, 10, 12, 0, 0, 0),
        catchup=False,
        tags=["hyper-dmp", "export", "trait", "ga", "dynamic_segment"],
) as dag:
    ...

property 중 schedule_interval 값을 6자리로 유지하면 안된다.

5자리 cron expression식으로 쓸것.

그러면 원했던 시간에 실행되는 것을 볼 수 있다.

다음으로

start_date

이 속성은 현재 시간보다 앞서나가면 실행이 안된다.

예약의 조건으로 사용하거나
catchup=true속성으로 지난 시간들의 모든 schedule을 가져올때 사용하던지 해야한다.

위 코드에 없는

execution_time

해당 부분을 dag이 실행될때 부여되는 속성이다.
이상하게도 schdule_interval을 6자리 할때도 execution_time은 정확하게 부여되었다.

중요한건 해당 execution_time이 실행될때 바로 전 타임 execution_time을 확인할 수 있다는 것이다.

예를들어

현재시간 : 13:00
with models.DAG(
        MAIN_DAG_ID,
        default_args=default_args,
        schedule_interval='*/30 * * * * *',
        start_date=datetime(2021, 10, 12, 0, 0, 0),
        catchup=False,
        tags=["hyper-dmp", "export", "trait", "ga", "dynamic_segment"],
) as dag:

위 코드로 현재시간에 실행된다면 execution_time값은 무엇일까 ?

답은

12:30

이다.

누군가의 설명에 따르면 schedule_interval 간격마다 바로 전 execution_time을 실행한다

로 이해하라고 되어있었다.

반응형

실패상황1

1Airflow에서 mysql_default를 사용중에 localhost:3306을 설정하여 커넥션을 시도하였으나
실패하였다.

실패상황2

docker inspect containerId 를 통해서 내부 ip를 파악해여 커넥션을 시도하였으나
실패하였다.

이유가 무엇일까 생각해보니 네트워크가 서로 분리되어있었다.

mysql은 기본 네트워크 (bridge)에 존재하였고

airflow는 생성할때 입력한 네트워크에 container들과 함께 생성되었다.

# 네트워크 리스트 명령어
docker network ls

# 해당 네트워크에 어떤 컨테이너가 있는지, 또는 정보를 확인하는 명령어
docker network inspect networkName

# docker network inspect bridge 
# docker network inspect "airflow network name"

서로 다른 네트워크에 존하는것을 확인하였다. 그렇다면 어떻게 해야할까 ?



내가 작업한 방법은 airflow network에 mysql container를 붙여서 내부 아이피를 사용하는 방법을 사용하였다.

먼저 local-mysql container를 bridge 네트워크에서 제거하는 명령어

docker network disconnect bridge local-mysql




이후 airflow network에 local-mysql을 붙이는 명령어

docker network connect "airflow network name" local-mysql




이후 잘되었는지 확인

docker network inspect "airflow network name"
# docker network inspect hyper-dmp-v2-workflow_default 결과

[
    {
        "Name": "hyper-dmp-v2-workflow_default",
        "Id": "97e809b8c591b205ab25ac0ac0c30efcbea1628cf0dbafb977a5ff00af551906",
        "Created": "2021-08-17T06:18:29.488748Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": true,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "290d92d8050eabee9e160f3e0439df8fb5d4d4d622a8f14317f68966c68d9947": {
                "Name": "workflow_airflow-worker_1",
                "EndpointID": "f28016d500d349b9dcc123db5f4312bca8226b6ebb3d4552f571b732b7e6be65",
                "MacAddress": "02:42:ac:12:00:05",
                "IPv4Address": "172.18.0.5/16",
                "IPv6Address": ""
            },
            "3ea2b515e45b2bd3d17b4e5b34f8ddb3ad5eb5d773c55a71724d7dfa7eb9a8c8": {
                "Name": "workflow_airflow-webserver_1",
                "EndpointID": "3e38cb185a20ba33157d363574b2fd6844c3834ebe633713321dbcd7ece26a4d",
                "MacAddress": "02:42:ac:12:00:07",
                "IPv4Address": "172.18.0.7/16",
                "IPv6Address": ""
            },
            "5a2cebcd308971a2db78a321ba99f304004111fcdffab2648f2264d8e156a359": {
                "Name": "workflow_airflow-scheduler_1",
                "EndpointID": "2cd982cea25db9651d98a503d9009e1ed20d68c09c513ca9c5894708d06b58ee",
                "MacAddress": "02:42:ac:12:00:04",
                "IPv4Address": "172.18.0.4/16",
                "IPv6Address": ""
            },
            **"8e68ca23d180eca523b5c1bc35d44c11c5ffab95b7734724279582313df5d0c9": {
                "Name": "local-mysql",
                "EndpointID": "e9dd16cdf8fdd1856cea04ee2ba74948928bd796b681f8182c81ac6ed1711f6e",
                "MacAddress": "02:42:ac:12:00:06",
                "IPv4Address": "172.18.0.6/16",
                "IPv6Address": ""
            },# 이 부분이 추가 된 부분**
            "b3788433fb68182e847b8d782e38cd07caffdf4f7de41bba59a8705d1cd00cc9": {
                "Name": "workflow_redis_1",
                "EndpointID": "6ed71a24bf27c327ed996fbaae0ade72bee75c4e371b80d11aefff8167aadef7",
                "MacAddress": "02:42:ac:12:00:02",
                "IPv4Address": "172.18.0.2/16",
                "IPv6Address": ""
            },
            "c3a4444096dd17a2d43449fc5c0273c786ba9c14cd328ef3818bc6724cd985d0": {
                "Name": "workflow_flower_1",
                "EndpointID": "27d9564194beebf24cced1e5802e5e49b2d55e2bc89cea6f4ef95d26481f2d6f",
                "MacAddress": "02:42:ac:12:00:08",
                "IPv4Address": "172.18.0.8/16",
                "IPv6Address": ""
            },
            "ce08580c8b40b50798a37ab39072e22f3bc9c37cae1fc9adb328ec5cc0b1ac53": {
                "Name": "hworkflow_postgres_1",
                "EndpointID": "d7640e67ec833bb595c4af43ce374d80eeaf049a70af8e0c9afc68c098e6a40f",
                "MacAddress": "02:42:ac:12:00:03",
                "IPv4Address": "172.18.0.3/16",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {
            "com.docker.compose.network": "default",
            "com.docker.compose.project": "workflow",
            "com.docker.compose.version": "1.29.1"
        }
    }
]

A네트워크에 Container를 붙여서 내부아이피를 사용하게 만드는 법이다.

보통 로컬 컴퓨터에 DB를 깔고 docker로 다른 제품을 사용하다보면 이렇게 네트워크까지 가지고있는 docker compoer파일들이 있는데
이런것들을 사용하던 로컬 DB와 혼용할때 유용하다.

반응형

젠킨스를 사용하다보면 상단의 업데이트가 표기된것을 볼 수 있다.

빨간 숫자 2

해당 표기를 눌러보면 Plugins, Jenkins 업데이트하라는 내용이 대부분이다.

젠킨스를 업데이트하여 최신의 기능을 빠르게 적용시켜보자.

젠킨스 경로

# 젠킨스 경로 이동
cd /usr/lib/jenkins

# jenkins.war 파일 확인
ls -al

# 최종 경로 
# /usr/lib/jenkins/jenkins.war

기존 jenkins file 백업

#기존의 jenkins.war는 백업
cp jenkins.war jenkins_20200529.war

{

젠킨스 업데이트 파일 다운로드

wget http://mirrors.jenkins-ci.org/war/latest/jenkins.war

또는

자신이 운영하는 젠킨스 사이트에서 업데이트 하라는 링크를 직접 입력한다. (버전이 명시적임)

wget $LINK

}

젠킨스 재시작

service jenkins restart
  • 젠킨스 파일 찾기
find / -name 'jenkins.war'
반응형

가끔 프로젝트를 생성하다보면 내가 원하지 않은 파일이 올라가있을때가 있다.

올라간것을 지우려면 직접 Github repository에 가서 변경하거나 귀찮게 작업을 해왔었다.

로컬에서 작업을 진행 후 push를 해서 반영가능하게 하는 작업을 아래와 같이 설명 한다.

아래는 bin폴더가 잘못 올라간 상황을 가정한다.

  1. git ignore 파일에 아래와 같이 추가, 작성한다.
bin/
  1. 아래와 같은 명령어를 실행한다.
git rm -r --cached bin

3. push 한다. 

git push 리모트-저장소이름 로컬-브렌치명


4. 리모트 저장소를 확인해보면 없어진것을 확인할 수 있다.

'Utils > Github' 카테고리의 다른 글

[Github] Projects 메뉴 활용  (0) 2021.01.10
[GitHub] 프로젝트 삭제 방법 - 웹  (0) 2016.09.15
반응형

SSH  계정 정책 설정

  • 적용된 운영체제는 Amazon Linux2 버전입니다.

Session Timeout 적용

# 해당파일 수정
vi ~/.bash_profile 
# 적당한 위치에 삽입
export TMOUT=60 (=1분)
export TMOUT=600 (=10분)
# 해당파일 수정
vi /etc/profile
#적당한 위치에 삽입
export TMOUT=60 (=1분)
export TMOUT=600 (=10분)

 

 

  • 아래 코드 사용해야 적용 됨.
# 적용 명령어
source /etc/profile
source ~/.bash_profile

 

 

 

 


 

아래 내용은 수정 시 즉시 반영됨. (곧 즉시 테스트 가능)

 

같은 계정을 한명 만 사용하는 설정

vi /etc/security/limits.conf

# 아래 사진에서 @keyclass1 이 아이디 할당하는 부분을 * 로해서 전체 아이디 에 적용되도록 해야함
# 예
# *    hard   maxlogins    1
vi /etc/pam.d/login

# 해당 내용 추가
# session required pam_limits.so

 

 

이전 사용한 암호 기억 설정 접근

vi /etc/pam.d/system-auth

# 2회까지 기억 함
password    sufficient    pam_unix.so try_first_pass nullok remember=2

 

 

비밀번호 정책 정의

**저장 이후로 생성된 계정들에 대한 정책**

# vi /etc/login.defs
PASS_MAX_DAYS   100
PASS_MIN_DAYS   0
# PASS_MIN_LEN  5
PASS_WARN_AGE   7
**이미 생성된 계정들에 대한 정책**

최대 사용기간
chage -M <days> <username>

최소 사용기간
chage -m <days> <username>

암호 만료 안내
chage -W <days> <username>

확인 
chage -l <username>

 

 

로그인 실패 시 후 잠금 처리

# 계정 제한 파일
vi /etc/pam.d/password-auth
# 아래 코드와 같이 적용되어야 한다
**auth        required      pam_tally2.so  deny=5 unlock_time=600**
...
account     required      pam_unix.so
**account     required      pam_tally2.so**

 

 

잠금상태 확인

# pam_tally2 사용법

#유저 잠금 확인 
pam_tally2 --user=my_user_id

#유저 잠금 해제
pam_tally2 --user=my_user_id -r

#전체 잠금 계정 확인
faillock

#실패 로그 삭제
faillock --user aaronkilik --r

 

 

 

참고 : http://i5on9i.blogspot.com/2018/07/linux-login.html

아래 명령어로 비밀번호 생성 규칙 정의

인스턴스에서 지원하는 형식을 확인 해야함.( 확인 경로 : /etc/pam.d/system-auth)
해당 파일 내에 (pam_cracklib.so / pwquality.conf) 확인하여 지원하는 한 형식으로만 작성해야함.

# vi /etc/pam.d/system-auth (pwquality.conf 형식)

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=5 minlen=8 lcredit=-1 dcredit=-1 ocredit=-1 authtok_type=
# vi /etc/pam.d/system-auth (pam_cracklib.so 형식)

password    requisite     pam_cracklib.so retry=5 **minlen=8 lcredit=-1 dcredit=-1 ocredit=-1**
  • root 계정으로 패스워드를 바꾸면 정책을 무시하고 다 바뀐다.
  • *일반 계정이 자기 자신의 비밀번호를 변경하려 할 때만 복잡도 설정이 적용* 된다

 

 

참고 : https://docs.aws.amazon.com/ko_kr/inspector/latest/userguide/inspector_security-best-practices.html#support-ssh-v2-only

모듈(pam_unix) : https://linux.die.net/man/8/pam_unix

모듈(pam_cracklib) : https://linux.die.net/man/8/pam_cracklib

모듈(pwquality.conf) : https://linux.die.net/man/5/pwquality.conf

 

 

 


 

위 내용 테스트 시 필요한 명령어

계정 추가

useradd 계정명

비밀번호 변경

passwd 계정명

새비밀번호:
새비밀번호 확인:

계정 목록 + 비밀번호 저장 파일

cat /etc/shadow

계정 목록

cat /etc/passwd
반응형

 

프로젝트 관리 및 업무파악을 하기 위해서 해당 메뉴가이드를 작업하다 내용을 가져와보았다.

이전에 JIRA로 전체 업무에 적용하여 작업을 해왔는데 참여도가 굉장히 저조했다. 

 

JIRA 툴 자체는 좋지만 업무특성에 맞게 적용하는것도 중요하다 생각이 들었다.

기획 디자인 개발 프로세스가 흘러가지만 갑에게 늘 휘둘리는 회사라면 

이런 업무툴은 업무시간을 까먹는 불필요한 프로세스라고 생각한다. 

 

추가적으로 툴을 여러개 섞어쓰는걸 별로라고 생각하는데 

그 이유는 로그인 비용과 부수적이 변화에 대한 적용 비용이 든다 생각하기때문이다. 

최소화시킬수있다면 업무동선이 많이 줄거라 생각이 든다.

 

 

깃허브 Projects 메뉴가 있기에 해당 내용을 파악해보았다. 

해당 메뉴는 JIRA와 비슷한점들이 많았다. 

 

글은 

1. 관리자가 구성하는 화면

2. 사용자가 구성하는 화면 

순서로 작성하였다.


 

 

먼저 관리자가 적용할 수 있는 화면을 구성해보았다. 

 

1. 팀프로젝트가 있다면 가장 루트, 팀 레파지토리 화면에서 > Projects 메뉴에 들어간다.

2. New Project 버튼을 클릭한다.

 

 

3. Project를 생성화면으로써 알맞는 값들을 선택한다. 

Template는 일단 None 선택을 한다.

 

 

4. 기존에 Repository를 만들어 두었다면 해당 프로젝트를 검색해서

Project와 Repository를 연결시켜준다.

 

 

5. 연결을 시켰다면 Create Project 버튼을 클릭하고 아래와 같은 화면이 보인다.

업무 프로세스를 추가하는 Column을 추가하는 화면이다.

 

 

6. Issue생성 기준으로 해당 컬럼에 자동으로 배치시키를 룰을 적용시킬수 있다. 
- To Do : 새로운 Issue가 생성될 경우
- In progress: 기존 이슈를 재오픈 할 경우
(강제로 In pregress로 변경 가능)
- Done: Issue를 Done처리 할 경우

 

 

7. 총 3가지 단계로 구성해 보았다. 

할일 > 작업중 > 끝 

이렇게 해두면 사용자에게 내 할일을 생성하여 끝내는 프로세스까지 진행하도록 공유해주어야 한다.

사용자들은 일할 Repository에서 이슈생성해서 Done처리를 하면
팀 레파지토리> Projects에서 전체를 이슈를 모니터링 할 수 있다.

 

 


 

 

+ 추가적으로 연결된 프로젝트를 추가하려면 아래 사진 순서와 같이 작업하면 된다.

1. 팀 레파지토리 > Projects 화면에서 내가 만든 Project에서 아래 사진과 같이 클릭

 

 

2. Linked repositories 메뉴에서 Link a repositroy 클릭

 

 

3. 연결될 레파지토리를 검색해서 입력한다. ( 추가된 레파지토리는 만들어져있는 상태여야 한다. )

 


 

 

사용자 프로젝트 작업 가이드

 

1. 업무가 있는 프로젝트에서 Issues 메뉴로 들어온다.

2. New issue 버튼을 클릭한다.

 

3. New issue화면에서 제목, 내용 및 할당될사람, issue lables, 어떤 Projects에 붙일 것인지 등 내용을 채워 나간다.

Lables는 기본적으로 9가지가 있다. 해당내용은 커스텀이 가능하다. 관리자와 내용을 조율하여 관리한다.

milestone은 일정을 생성하여 적용할 수 있는 기능이다. 
조금 번거로워 보인다.

3-1. 내용을 선택하는 화면이다. (참고)

 

 

4. 생성하고나면 이렇게 완료된 화면이 나온다.

+ 이렇게 추가된 프로젝트는 팀 레파지토리에서 관리되는 칸반보드에서 모두 확인이 가능하다.

 

 

+ Done처리 방법

1. 생성된 Issue에 들어가서 Close issue 버튼을 클릭한다.

 

2. 칸반보드에서 내용 확인

 

 

+ In progress 처리 방법

해당 issue화면에서 프로세스 상태값을 변경한다. 
자동으로 할당도되는데 
관리자와 해당 룰을 설명 받은뒤 사용자들에게 공유하면 될 것으로 보인다. 

 

'Utils > Github' 카테고리의 다른 글

[Github] Git ignore 등록 후 Remote 동기화하기  (0) 2021.01.26
[GitHub] 프로젝트 삭제 방법 - 웹  (0) 2016.09.15
반응형

여러가지 적용해보았는데 제일 괜찮았던 테마이다.

 

https://chrome.google.com/webstore/detail/dark-reader/eimadpbcbfnmbkopoojfekhnkhdbieeh/related

 

Dark Reader

모든 웹사이트에 다크 모드를 적용합니다. 밤이나 일상적인 웹 브라우징을 할 때 어두운 테마를 사용하여 눈을 보호하십시오.

chrome.google.com

 

별점 높은것도 깔아서 사용해보았는데 이게 제일 나았던거 같다. 

물론.. 개발자들은 내가 어떤색상을 적용시켰는지 확인하려면

테마를 걷어내야겠지만 ...!

반응형



1. 깃허브 메인 페이지에 접속 한다.



2. 삭제 할 프로젝트 repository를 클릭한다.





3. 깃허브 메뉴 툴바에 있는 Settings 항목을 클릭하고

4. Delete this repository를 클릭하고 해당 프로젝트 이름을 다시 입력하면 

삭제할 프로젝트가 삭제된다.

'Utils > Github' 카테고리의 다른 글

[Github] Git ignore 등록 후 Remote 동기화하기  (0) 2021.01.26
[Github] Projects 메뉴 활용  (0) 2021.01.10

+ Recent posts