반응형

내가 다른 나라를 여행할 때, 스스로에게 다짐하는 것이 하나 있다.

웬만하면, 블로그, YouTube에 많이 소개된 장소는 가지 말자 !!!

 

방문할 도시의 대중교통(버스, 전철, 택시) 이용법 정도만 미리 숙지하고, 간단하게 그 나라의 언어와 문자만 익히고 떠나는 것이 재미있어졌다.  어떤 일이 펼쳐질지 예상하지 못하고 떠나는 여행이라... 기대되지 않는가? ^^

가끔 YouTube, 블로그에서 맛집이라고 소개한 곳을 한번 가보기는 하는데, 항상 그런 식당(맛집)에 가보면 사람이 많고 오래 기다려서 먹어야 하고, 게다가 주방장이 많은 음식을 끊임없이 조리해서 그런지, 그리고 주방장이 과로하고 지쳐서 그런지 맛은 평범한 식당보다 맛이 없었다.

귀한 시간을 쪼개서 여행을 갔는데, 식당 앞에서 1시간씩 기다린다는 것이 아깝다. 10분 이상 기다려야 하는 상황이면 과감하게 그 식당은 Skip~

 


 

이번에는 아들과 딸의 졸업을 축하하는 여행을 떠나기로 했다.

즉, 여행의 주인공은 내가 아닌 아들과 딸이다.

그래서 여행 일정 계획과 방문할 도시는 아들과 딸에게 정하라고 했고, 나는 아들과 뒤를 따라다니기로 미리 정해놓았다.

(나는 보디가드 역할만 하는 것으로~~~)

이번 여행에서는 엄마도 빠졌다. 내가 그림자처럼 옆에 있는 것을 빼고는 아들과 딸이 스스로하는 여행과 마찬가지다.

아들이 약간의 일본 말와 일본 문자를 공부하고, 이렇게 짧게 준비한 어휘만으로 오사카, 교토 여행을 떠났다.

 

Tip:  공황 장애에 관하여.

내가 공황 장애가 심하게 있어서 간사이공항을 가는 항공기 중에서 제일 큰 비행기로 예약했다.
그리고 항공기 탑승 2시간 전쯤에 정신과 병원에서 받은 공황 장애 치료제를 먹었다.
물이 없을 때는 그냥 알약을 입에 넣고, 약간의 침과 함께 삼켜도 된다.

 

Tip: 주유패스, 라피트 패스 같은 여행자를 위한 통합 패스 구입 여부.

결론부터 말하면, 오사카에 가기 전에 미리 구입한 여행 패스는 1개도 없다.
한국에서 구입한 주유패스를 간사이공항(또는 오사카 시내)에서 기다리고 교환하는 절차가 번거롭고, 그 시간이 아까웠다.
그냥 간사이공항에서 ICOCA IC Card 1장씩 자판기에서 구입해서 각자 15,000엔(대락 15만원)씩 충전해서 다녔다.
그리고 라피트 타려면 패스 구입하기 위해 줄도 서야 하고 라피트 출발 시간도 딱 맞춰야 하는데, 이러는 시간을 다 포함하여 비교해보면 한산한 키오스크에서 ICOCA IC Card를 구입해서 전철 아무거나 타고 시내로 가는 것이 실제 도착시간으로 보면, 더 일찍 도착한다. 참으로 역설적이다. 싼 전철이 비싼 라피트보다 시내에 더 일찍 도착하다니...

만약, 관광지를 두루두루 다 다녀볼 생각이라면 주유패스가 살짝 이득이다. (그런데 주유패스가 되는 관광지가 그닥 매력적이지 않다. 그 돈을 지불하면서 볼만하거나 체험할 만한 것인지 ........ )

 


Day 1  :  인천공항 -> 간사이공항 -> 오사카 시내

 

인천공항 탑승게이트에서 기다리기

 

코로나19 때문에 일본에 입국할 때 검역이 까다롭고 입국 심사가 길어졌다는 얘기를 들었는데, 

내가 비행기에서 내리면서 시계를 보고, 입국 심사를 완전히 마칠 때까지 걸린 시간을 측정해보니 대략 25분 정도 걸렸다.

(이게 검역 심사가 맞나 싶을 정도로 대충대충... 뭐 그냥 좋은게 좋은거다... 이런 느낌으로 검역 심사가 끝남)

 

입국심사 대기 줄만 길 뿐, 지하철 환승 통로처럼 쭉쭉 앞으로 나간다. 이 복도를 지나는데 대략 5분 정도 걸린 듯.  아무튼 통로에 사람이 많지만 금방금방 앞으로 진행한다.

 

입국 심사 끝나고, 바로  전철역으로 이동하고, 전철역 키오스크에서 ICOCA IC 카드를 구입했다. 

우리는 ICOCA 카드에 넉넉하게 1인당 15만원 정도(15,000엔) 충전했다.

전철 버스 요금 지불, 편의점에서 결제, 백화점에 있는 식당에서 식사할 때 대부분 ICOCA 카드로 결제가 되니까 넉넉하게 15만원씩 충전했다. (결론적으로 말하면, 이렇게 총 45만원을 ICOCA 카드에 충전했는데 다 쓰고 왔다)

일단, 잔돈(동전)이 안 생기니까 좋고, 결제할 때 빨리 처리되니까 좋다.

 

참고:
아래 빨간색 NAKAI, 파란색 JR Tocket Office 중에서 대기줄이 없는 키오스크에서 구입하면 된다.
다른 블로그를 보니 빨간색 쪽에서 사거나 파란색 쪽에서만 ICOCA 카드를 사야하는 것처럼 글을 썼던데, 그런거 없다.
그냥 대기줄이 없는 키오스크 쪽에서 사면 된다.

 

ICOCA 카드 구입하고, 전철 개찰구 통과해서 NAMBA까지 가는 급행 전철(Limited Express Train)을 타기까지 전체 과정에서 대략 3분 정도 걸린 것 같다. 급행 전철이 자주 와서, 굳이 더 비싼 특급열차 또는 라피트 티켓을 구입할 필요가 있나 싶다.

 

숙소를 Juso 지역으로 정했기 때문에 KIX(간사이공항역) -> NAMBA -> Umeda -> Juso 이런 식으로 전철을 환승하면서 이동했다.

NAMBA 전철역은 그럭저럭 서울과 비슷한 수준의 환승 복잡도가 있었는데, Umeda 전철역은 신도림역의 2배 정도 복잡한 느낌이었다. 

해외 여행하면서 전철 환승 때문에 머리를 이렇게 많이 써본적이 있나 싶다.

Google Maps가 워낙 길 설명을 잘 해줘서, Google Maps의 코멘트만 잘 따라하면 솔직히 길을 헤메지 않는다.

환승할 전철, 지하철의 입구 번호, 그리고 플랫폼 번호까지 다 안내해주니까 그냥 Google Maps 화면에 보여지는 글을 읽으면서 그대로 따라가보시라~~

 

간사이 공항에서 급행 열차(Limited Express)를 타고 Namba 지역으로 이동 중

 

 

 

 

참고 정보:

일본 호텔은 다른 나라의 호텔보다는 사이즈가 작다.
예를 들어 2인이 투숙할 Standard Room이 다른 나라의 Standard Room의 70% 수준 정도의 크기가 되는 것 같다.
그래서 나는 일본에 갈 때 글로벌 체인 호텔(예: 힐튼호텔)을 이용하거나 Airbnb 같은 것을 이용하여 숙소를 렌탈하는 방식으로 이용한다. 이 방식으로 숙소를 이용하는 것이 같은 비용이면 대략 1.5배 정도 사이즈가 더 크다.

 

어짜피 이번 여행에는 NAMBA, Umeda  지역에는 잠깐 물건 구입하러 가고, 그 외에 Namba, Umeda 지역에 갈 일이 없기 때문에 시내에서 살짝 벗어난 주택가 지역으로 숙소를 정했다. 이 선택은 정말 잘 한 것 같다. (Juso 지역의 동네 야구장 바로 옆)

아침이나 저녁에 동네 주민들 왔다갔다 하는거 구경하는 재미도 있고, 골목길에서 동네 꼬맹이 노는 모습도 볼 수 있어서 좋았다.

(한국에서는 꼬맹이들이 골목길에서 친구들끼리 육체적으로 노는 모습을 본지가... ㅠㅠ)

어릴 적 내가 놀던 모습도 떠오르고 해서, 시계를 거꾸로 돌려 1980년대에 잠시 다녀온 기분이다. ^^

 

첫날 저녁은 지친 몸을 이끌고 식당까지 가기가 귀찮아서 편의점에 나가서 도시락을 구입해서 숙소에서 뎁혀서 먹었다.

그리고 바로 꿀맛같은 잠을 잤다. (진짜 많이 피곤했나 보다)

 


Day 2

간사이대학교

아침에 일어나서 바로 간 곳은 간사이대학교이다.

 

철도 건널목을 한번도 건너보지 못한 아이들. 건널목이 있는 이 풍경이 신기하다고 하네.

 

간사이대학교 주변에 있는 주택이 참 예쁘다.

정문쪽은 대부분의 대학교가 그렇듯 상권이 발달하다보니 어수선하고 지저분하다.

정문 방향을 제외하고는 대학교 주변 반경 500미터 정도는 주택이 고급지게 예뻤다. (대학교보다는 주변 주택가를 더 많이 걸은 듯...)

그리고 간사이대학교가 높은 지대에 있다보니 시내가 내려다 보였다. (이화여대에 가면 서울 시내가 내려다보이는 것처럼 ㅎㅎ)

 

간사이대학교 주변 주택가
대학교 펜스 바로 옆 길에 아기자기한 주택 모양이 많았다.

 

대학교 펜스 바로 옆 길에 아기자기한 주택 모양이 많았다.

 

 

대학교 건물 내부에도 들어가보고, 실내 구석구석 구경했다.

 

간사이대학교 건물 내부.  자유롭게 가져가라고 해서 인쇄물을 1개 가져왔다.

 

강의동 건물 내부에 있는 공중 전화기.  1990년대 감성이 돋네 ^^

 

대학교 간 축구 경기가 있어서 축구장에서 30분 정도 경기하는 것을 구경했다.

이게 대학교 축구장이 맞나 싶을 정도로 정말 그라운드 상태가 좋았다.

잔디 상태 좋고, 대학생 선수 실력도 수준급이다. 골이 많이 나와서 재미있는 경기였다.

 

 

그리고 바로 옆에 야구장이 있어서 야구하는 것도 봤는데, 여기서 살짝 오해를 산 것 같다.

나랑 아들이랑 워낙 야구를 좋아하다보니, 야구 선수 한명 한명 수비 폼을 보면서 분석하는 대화를 했더니 선수들이 내 옆에 와서 90도 꾸벅 인사를 하고 가더라. ㅜㅜ

아... 혹시 스카우터로 착각한게 아닐까 라는 생각이 들었다.

그래서 더 오해를 사기 전에 그 자리를 떠났다. ^^

 

나와 아들이 포지션 별, 수비 자세를 지적하는 대화를 나누었더니 스카우터로 오해를 받은 것 같다.

 

 

아메리카무라 악기 상가, Namba 근처 애니메이트 상가

간사인대학교에서 아메리카무라(アメリカ村)로 이동 중

 

기타 판매, 수리하는 샵이 있어서 전자기타 용품을 구입하러 입장

 

가격이 참 착하네. 구매 욕구를 땅긴다.

 

 

둘째 아들이 같이 왔으면, 진짜 좋아했을 기타 샵이다.

 

 

이번 여행에 같이 못 온 둘째 아들에게 이 사진을 보내고, 아들이 골라서 주면 내가 사주겠다고 했으나 마음에 드는게 없다고 한다.

 

 

도톤보리 글리코상에 갈 계획은 없었는데 악기 상가 갔다가 애니메이트 상가를 가는 중간에 있어서 사진만 한컷 찍었다.

 

애니메이트 상가에서 책 몇 권 구입하고, 숙소로 돌아가는 길에 배고픔이 밀려왔다.

그래서 어짜피 숙소를 가려면, Umeda에서 환승해야 해서 한큐백화점 꼭대기 층에서 식사하고 돌아가기로 했다.

비싼 가격 만큼이나 정갈하고 서비스 좋고, 담백한 맛이 좋았다.

밥 먹고 한층 더 올라가니, 한큐백화점 라운지가 있어서 그곳에서 야경 보면서 30분 정도 떠들다가 숙소로 발길을 돌렸다.

 

 

 


 

Day 3

숙소에서 간단하게 아침 식사를 하고, 교토로 출발했다.

숙소가 오사카에서 교토로 나가는 길목에 있어서 급행 열차를 타니까 금방 교토에 도착했다.

교토로 가는 급행 전철.  속도가 빠르다. (새마을호 열차만큼 빠른듯)

 

이 급행 전철도 ICOCA Card로 타면 된다.

 

참고 정보:

교토에 갈 때, 1일 교통패스를 구입하는 분들이 꽤 있던데
버스를 타고 이동할 만큼 관광지와 관광지가 멀리 떨어진 곳이 별로 없다.
아주 빡시게 뛰어다니면서 투어할 생각이 아니라면, 1일 교통패스가 별로 의미가 없다.
여유있게 걷고, 차 한잔 마시고, 식사 한끼 하고 그러다보니... 버스는 2번 정도 타게 된다.
그러니까 교통패스를 따로 구입하는 수고스러움을 덜고, 그냥 간편하게 ICOCA 카드 한장으로 돌아다녀도 된다.

 

 

옛스러움이 느껴지는 거리

 

 

거리를 걷다가 텅빈 카페가 있어서 들어왔다.  카페 내부에 정원이 있어서 여유가 느껴진다.

 

 

이 사진을 찍을 때만해도 사람이 이 정도 였지만, 1시간 뒤에 다시 이 길을 되돌아 나올 때는 사람 밖에 안 보일 정도로 많아졌다.

 

 

 

윤동주 시인, 그리고 도시샤 대학교

 

어느 도시를 여행하든, 나는 그 도시에서 역사가 깊은 대학교를 꼭 가본다.

교통에는 윤동주 시인의 발자취를 볼 수 있는 대학교가 있어서 가봤다. 

우리한테는 발음도 어색한 도시샤대학교.

그렇지만, 이 학교에 대해 알아보니 역사가 엄청나게 길다.

그리고 직접 와서 캠퍼스를 보니... 정말 시를 쓰고 싶게 만드는 풍경을 가지고 있다.

겨울에 와서 봤을 때 이 정도 풍경이라면, 봄 ~ 가을에는 정말 죽여주는 풍경일것이다.

 

 

도시샤대학교 옆에 있는 문화당커피점

 

 

문화당커피점 내부

 

문화점커피점 창문을 통해 보이는 도시샤대학교 캠퍼스

 

카페 내부 분위기, 서빙하는 웨이터, 창 밖으로 보이는 캠퍼스 풍경 등 모든 것이 참 좋았던 "문화당커피점"

내가 이 카페를 방문하기 열흘 전에 아사히신문사에서 인터뷰도 하고 갔었네 (아래 신문 내용)

그리고 신기하게도 이 문화당커피점 웨이터(젊은 여성 직원)은 영어가 유창하다. 지금까지 만나 본 일본인 중에서 제일 영어를 잘 구사했다.

내가 이런 저런 사정이 있어서 막내딸만 카페에 두고, 나랑 아들만 도시샤 대학교와 주변을 돌아보고 다시 카페에 돌아와서 딸을 데리고 갈테니 식사 및 음료 비용을 먼저 결제하고 그 사이에 딸이 이 곳에서 안전하게 머물게 해줄 수 있냐라고 부탁했는데, 영어를 정확하게 알아듣고 웨이터도 본인이 개인적으로 궁금한 것도 우리에게 영어로 물어봤다.

이 카페 웨이터가 영어를 잘 해야 할 수 밖에 없는 것이, 카페에 일본인보다는 도시샤대학교 교수진처럼 보이는 백인들이 더 많았다. 주고객층이 영어를 사용하는 외국 교수진 같았다.

 

 

 

 

 

동서남북, 모든 방향으로 예쁜 건물이다.

 

 

 

도시샤대학교에서 전철을 타고, 다시 숙소가 있는 오사카로 가는 중

 

숙소에서 30분 정도 쉬고, 근처 주택가에 있는 식당으로 저녁 먹으로 나갔다.

식당을 정하고 간 것은 아니고, 주택가를 걷다가 아무데나 좋아 보이는 식당을 가기로 했다.

 

숙소에서 걸어서 10분 거리에 있던 식당. レストラン龍

 

 

 

식당 안 책장에 만화책이 있어서 꺼내 읽는 재미가 있다.

 

 

 

 

 

 

Day 4

여행 마지막 날~

오사카 나이키 매장가서 운동화 구입하고, 가족과 직장 동료에게 줄 선물 구입하느라 백화점을 이리저리 돌아다녔다.

그러다가 백화점 꼭대기 층에 씨티뷰가 너무 좋은 식당이 있어서, 묻지도 따지지도 않고 바로 식당 내부로 직행.

기대하지 않아서 그런가 맛 좋고, 분위기 좋고, 뷰는 더욱 좋고... 더할나위 없이 좋은 오사카 마지막 식사였다.

돌아다니다가 얻어걸린 식당치고는 아주 만족스러웠다.

(전망이 좋아서 그런지, 음식 가격은 비싸다)

 

 

반응형

 

 


테스트는 나중에 하고, 오늘은 아래 블로그를 정독하고 이해만 하기로 함~~~~

 

https://jerryljh.tistory.com/40

 

Kubernetes Snapshot 백업/복구

Kube 환경에서도 기존 storage 벤더에서 제공하는 snapshot 기능을 사용 가능합니다. kube 환경답게 snapshot도 manifest YAML 파일 형태를 사용합니다. 그럼, 테스트 내역 공유합니다. Test 내역 snapshot 지원 sto

jerryljh.tistory.com

 

반응형

 


글 작성한 날짜: 2023년 2월 22일

 

자세한 테스트 내용은 나중에 작성하고, 오늘은 튜닝하면서 참고했던 문서만 리스팅~

 

Ceph를 실행할 때 Linux 커널에 대한 튜닝 고려 사항 (redhat 문서)
https://access.redhat.com/documentation/ko-kr/red_hat_ceph_storage/5/html/object_gateway_guide/tuning-considerations-for-the-linux-kernel-when-running-ceph_rgw

 

 


MariaDB + Ceph 조합으로 성능 테스트한 블로그 참고
  - https://ablog.jc-lab.net/230

 

 

[ 테스트 여담 ]
처음 Ceph cluster를 구축할 때, Storage로 HDD를 사용했었다.
그러다가 1개월 후에 SSD로 변경했는데 Bandwidth는 미미하게 커졌고, IOPS 값이 많이 상승했다.
mariaDB 처럼 OS Cache 사용을 원천적으로 막은 DB 제품은 Transaction이 빈번하게 발생하는데, 이런 경우 SSD를 사용하면
엄청나게 큰 효과를 볼 수 있다.
반면 큰 파일을 write, read 하는 Use case라면, ceph storage로 HDD를 사용하든 SSD를 사용하든 성능 면에서 큰 차이는 없다.

 

 

 

 

 

반응형

 


글 작성 및 테스트한 날짜: 2023년 2월 21일

 

<< 참고 문서 >>

InnoDB(MariaDB, MySQL) System Variables 전체 목록 및 상세 설명 문서
  - https://mariadb.com/kb/en/innodb-system-variables/

DB 관리 목적의 SQL (예: show, backup, analyze, kill, reset, use)
  - https://mariadb.com/kb/en/administrative-sql-statements/

 

 

자세한 설명을 하기 전에 설정 파일 예제부터 보자.

$ cat /etc/mysql/conf.d/mariadb.cnf

[client-server]
port = 3306
socket = /run/mysqld/mysqld.sock

[mariadbd]
server-id = 1
bind-address = 0.0.0.0
lower_case_table_names = 1

... 중간 생략 ...

##
## NOTE: 성능 테스트를 위해 아래 4개 항목을 변경하면서 Query Per Second를 측정해봤다.
##
innodb_flush_log_at_trx_commit = 0
innodb_flush_method = O_DIRECT_NO_FSYNC
innodb_flush_sync = OFF
innodb_use_native_aio = OFF

... 중간 생략 ...

$

 

 

Transaction Commit Log에 대한 Flush 여부 설정

설정 항목: innodb_flush_log_at_trx_commit

 

##
##  innodb_flush_log_at_trx_commit 설정 변경
##


MariaDB [(none)]> show variables like '%innodb_flush_log_at%';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_flush_log_at_timeout    | 1    |
| innodb_flush_log_at_trx_commit | 0     |
+--------------------------------+-------+
2 rows in set (0.001 sec)

MariaDB [(none)]> set global innodb_flush_log_at_trx_commit=0;
Query OK, 0 rows affected (0.000 sec)

MariaDB [(none)]>  show variables like 'innodb_flush_log_at_trx_commit';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 0     |
+--------------------------------+-------+
1 row in set (0.000 sec)

MariaDB [(none)]>

 

위 설정 관련 참고 문서:  innodb_flush_log_at_trx_commit 개념 그림 및 튜닝
https://yunhyeonglee.tistory.com/41

 

Flush method 개념

설정 항목: innodb-flush-method

아래 문서를 참고

-  https://medium.com/releem/innodb-flush-method-cbe0ebba8acb
-  https://dus815.tistory.com/entry/Mysql-InnoDB-%EC%97%90%EC%84%9C-OS-Cache-%EC%99%80%EC%9D%98-%EA%B4%80%EA%B3%84

그런데 mariaDB, MySQL 버전이 올라오면서 최근에는 이 설정값을 변경할 수 없다.

 

 

 

 

반응형

 


 


테스트한 날짜:  2023년 2월 20일

 

 

 

DD 명령으로 Storage I/O 성능 확인

 

############################################################################
## 쓰기(output) 성능 확인
############################################################################

## Case: 저장 장치의 Cache memory(즉, Buffer memory)를 사용하는 경우
$ dd if=/dev/zero bs=1024 count=5000 of=/mnt/hdd1/my_test_file
5000+0 records in
5000+0 records out
5120000 bytes (5.1 MB, 4.9 MiB) copied, 0.0113672 s, 450 MB/s
$

## Case: 저장 장치의 Cache memory(즉, Buffer memory)를 사용하지 않는 경우,
##       oflag=direct  옵션을 추가한다.
$ dd if=/dev/zero bs=1024 count=5000 of=/mnt/hdd1/my_test_file oflag=direct
5000+0 records in
5000+0 records out
5120000 bytes (5.1 MB, 4.9 MiB) copied, 0.23691 s, 21.6 MB/s


############################################################################
## 읽기(input) 성능 확인
############################################################################

$ dd if=/mnt/hdd1/my_test_file of=/dev/null bs=1024
5000+0 records in
5000+0 records out
5120000 bytes (5.1 MB, 4.9 MiB) copied, 0.0123259 s, 415 MB/s
$

 

 


 

반응형

 


 

작성일: 2024년 2월 21일

 

Shell script 작성할 때마다 책꽂이 어딘가에 있을 책을 찾는 것이 귀찮고, 인터넷에서 검색하는 것도 귀찮아서, 
내가 자주 사용하는 Shell script use case를 정리하는 것이 편하겠다는 생각이 들었다.

 

 

Bash Shell Programming 추천 문서

추천 문서 1

  • Link: https://www.lesstif.com/lpt/bash-shell-script-programming-26083916.html
  • 이 문서가 다루는 내용
    • For loop
    • Script parameter, argument ($0, $1, ... $n, $@)   // CLI를 통해서 받은 argument를 처리하는 방법
    • getopt
    • compare operator (비교 연산자, if then fi, else, elif, ... )
    • File test (디렉토리 존재 여부, 파일 존재 여부, 실행 파일 여부 등 검사)
    • String test (문자열이 공백인지 검사,  Regular expression 정규식)
    • File 읽기 (Text file을 line by line으로 읽어서 변수에 담기)
    • nohup + stdin/out redirect (스크립트를 background로 실행시켜 terminal이 끊길 때 스크립트가 종료되는 것을 방지)
    • EUID 활용법 (일반 계정, root 계정으로 실행했는지 테스트)
    • $? 변수 체크 (외부 명령을 실행 후, 그 결과가 성공/실패인지를 체크)

추천 문서 2

  • Link: https://velog.io/@markyang92/declaretypeset
  • 이 문서가 다루는 내용
    • 변수 이름 작명 규칙
    • 변수 선언, 변수 사용(값 참조)
    • eval 키워드 사용법
    • export, declear, set 키워드를 사용하는 이유 및 활용 사례
    • unset, typeset 키워드 사용 사례
    • 미리 정의된 환경 변수 (HOME, PATH, LANG, SHELL, USER, DISPLAY, PS1, PS2, LINES, LS_COLORS 등)

추천 문서 3

  • Link: https://blog.gaerae.com/2015/01/bash-hello-world.html
  • 이 문서가 다루는 내용
    • function 선언, function 참조
    • 변수 선언, 변수 사용(값 참조)
    • 예약 변수(Reserved Variable): FUNCNAME, SECONDS, SHLVL, PPID, BASH_ENV, BASH_VERSION, OSTYPE
    • 위치 매개 변수(Positional Parameters): $0,  $1,  $*,  $@,  $#
    • 특수 매개 변수(Special Parameters): $$,  $?,  $!,  $-,  $_
    • 매개 변수 확장(Parameter Expansion): ${변수:-단어}  ${변수#단어}  ${변수/%찾는단어/변경단어}
    • 배열 변수(Array Variable): ${array[3]}  ${array[@]}
    • 변수 타입 지정(Variables Revisited): declare, typeset
    • 논리 연산자(Logical Operator):  &&  -a   ||  -o
    • 산술 연산자(Arithmetic Operator):  **  +=  -=  *=  /= %=
    • 비트 연산자(Bitwise Operator):  <<   <<=  >>=  &   &=  |   |=  ~   ~  ^   ^=
    • 정수 비교(Integer Comparison):  -eq  -ne  >  -gt  >=  -ge  <  -lt  <=  -le
    • 문자열 비교(String Comparision):  =  ==  !=  <  >  -z   -n
    • 파일 비교 연산자(File Test Operator):  -e  -f  -s  -d -b  -c  -p  -nt  -ot  -ef
    • 반복문: for  while  until
    • 조건문:  if elif  else  fi
    • 선택문:  case ... esac
    • 디버깅 방법: Dry run (bash -n my-run.sh)

 


 

유용한 스크립트 예제 모음

 

Remote node의 파일을 가져와서 Local node의 파일과 동일한지 확인 후 Local 장비에 반영하거나 삭제

아래 스크립트에서 유용한 부분은

  • date(날짜) 출력 포맷을 가공
  • 여러 단어(Word)로 구성된 문자열을 cut 명령으로 자르기(cut, split, delimiter)
  • if 조건문 사용
#!/usr/bin/bash

MY_REMOTE_ACCT=my-id@my-domain.kr

CUR_DATE=`date +%+4Y-%m-%d-%H-%M-%S`
ORIGIN_FILE="my-domain.kr.zone"
REMOTE_FILE="${ORIGIN_FILE}_remote"
BACKUP_FILE="${ORIGIN_FILE}_${CUR_DATE}_bkup"
DIR_PATH=/var/cache/bind

cd $DIR_PATH

scp ${MY_REMOTE_ACCT}:${DIR_PATH}/${ORIGIN_FILE} $REMOTE_FILE

## cksum 명령의 결과가 3개의 컬럼으로 출력되는데, 
## 실제 필요한 데이터는 첫번째 column이라서 출력 내용을 cut -f 1 명령으로 잘라냄.
CKSUM_REMOTE_FILE=$(cksum $REMOTE_FILE | cut -d " " -f 1)
CKSUM_ORIGIN_FILE=$(cksum $ORIGIN_FILE | cut -d " " -f 1)

if [ $CKSUM_REMOTE_FILE -eq $CKSUM_ORIGIN_FILE ]; then
        echo "The ${CKSUM_REMOTE_FILE} and the $CKSUM_ORIGIN_FILE are equivalent"
        exit 1
fi

echo "The ${CKSUM_REMOTE_FILE} and the $CKSUM_ORIGIN_FILE are different"

cp $ORIGIN_FILE $BACKUP_FILE
cp $REMOTE_FILE $ORIGIN_FILE

systemctl restart bind9

 

 

##

## TODO: 나중에 추가로 예제를 작성하기

##

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


 

반응형

 


작성일: 2024년 3월 27일

 

 

Oracle Cloud Infra(OCI) 그리고 Kubernetes Engine(OKE)를 사용하면서 참고하기 좋은 블로그를 찾았다.

타이틀은 개인 기술 블로그이지만, 거의 Oracle Cloud Infra의 공식 사용 매뉴얼 같은 느낌이다.

Oracle Cloud Infra의 공식 문서보다 사용자 입장에서 잘 작성된 글이다.

 

https://thekoguryo.github.io/

 

TheKoguryo's 기술 블로그

 

thekoguryo.github.io

 

공식 홈피에는 너무 많은 자료가 있어서 다 읽기 부담스러운데, 이 블로그는 딱 필요한 부분만 설명되어 있고

대부분 시간순으로 글이 진행되니까 따라서 실행하면 되는지라...

처음 OCI를 접하는 사람이 한번 쭉~ 읽고 OCI를 사용하면 좋을 것 같다.

 

반응형

 


 


테스트한 날짜: 2023년 2월 14일

 

 

아래와 같이  /etc/containers/registries.conf.d/myregistry.conf 파일에 container image registry의 주소를 추가한다.

만약, 8080, 8443 같은 포트를 사용한다면 domain name 뒤에 :8080, :8443 값을 붙여주어야 한다.

 

 

(참고:  아래 2개 명령 중에서 첫번째 명령만 수행해도 잘 동작한다 ^^)

 

$  cat > /etc/containers/registries.conf.d/myregistry.conf <<EOF

[[registry]]
location = "registry.myexample.kr"
insecure = true

EOF

$


$  cat > /etc/containers/registries.conf.d/your_registry.conf <<EOF

[[registry]]
location = "registry.your-example.kr:8443"
insecure = true

EOF

$

 

 

위와 같이 conf 파일만 작성하고 바로 podman 명령을 수행하면 잘 동작한다.

 

 

$  podman login registry.myexample.kr

Username: gildong
Password:
Login Succeeded!

$

 


 

+ Recent posts