[Git] branch naming

Git 2022. 9. 21. 10:39

- @참고: https://junjunrecord.tistory.com/131

- @참고(git branch & naming): https://velog.io/@kim-jaemin420/Git-branch-naming

 

branch 네이밍 규칙

1) master branch, develop branch

그대로 사용이 일반적

2) feature branch

feature/기능요약 형식 추천. ex) feature/login

feature/{issue-number}-{feature-name} 의 이슈추적 형식. ex) feature/1-init-project, feature/2-build-gradle-script-write

3) release branch

release-{version} 형식 추천. ex) release-1.2

4) hotfix branch

hotfix-{version} 형식 추천. ex) hotfix-1.2.1

블로그 이미지

uchacha

개발자 일지

,

- imbedded tomcat 에 jndi 적용

https://jforj.tistory.com/128
1. build.gradle 에

org.apache.commons:commons-dbcp2 dependency 추가

2. resource 설정 클래스 JndiResource 생성

@Configuration
public class JndiResource {
	@Bean
	TomcatServletWebServerFactory tomcatFactory() {
		return new TomcatServletWebServerFactory() {
			@Override
			protected TomcatWebServer getTomcatWebServer(Tomcat tomcat) {
				tomcat.enableNaming();
				return super.getTomcatWebServer(tomcat);
			}
			
			@Override
			protected void postProcessContext(Context context) {
				context.getNamingResources().addResource(getResource());
			}
		}
	}
	
	public ContextResource getResource() {
		ContextResource resource = new ContextResource();
		resource.setName("jndi/mysql"); // 사용될 jndi 이름
		resource.setType("javax.sql.DataSource");
		resource.setAuth("Container");
		resource.setProperty("factory", "org.apache.commons.dbcp2.BasicDataSourceFactory");
		
		// datasource 정보
		resource.setProperty("driverClassName", "com.mysql.cj.jdbc.Driver");
		resource.setProperty("url", "jdbc:mysql://localhost:3306/test?serverTimezone=UTC");
		resource.setProperty("username", "root");
		resource.setProperty("password", "root");
		return resource;
	}
}

3. applicaion.properties 에
spring.datasource.jndi-name: jndi/mysql

 

- external tomcat 에 jndi 적용

https://pkguma.tistory.com/269
https://solbel.tistory.com/284
0. external war 로 build 하도록 설정

1. application.properties 에
spring.datasource.jndi-name:jndi/mysql

2. tomcat server.xml 에 Resource 추가

<GlobalNamingResources>
	...
	<Resource auth="Container"
		name="jdbc/mysql"
		driverClassName="com.mysql.jdbc.Driver"
		type="javax.sql.DataSource"
		maxActive="8" maxIdle="8" maxWait="-1"
		url="jdbc:mysql://localhost:3306/test?serverTimezone=UTC"
		username="root"
		password="root" />
</GlobalNamingResource>

3. tomcat web.xml에 ResourceLink 추가

<Context>
...
	<WatchedResource>...
	<ResourceLink name="jdbc/mysql"
		global="jdbc/mysql"
		auth="Container"
		type="javax.sql.DataSource" />
</Context>

 

에러 해석

1. 

jndi 는 오타 등으로 Resource 정보가 잘못되었을 때 아래와 같이 DataSourceLookupFailureException 에러를 뱉었다.

jndi Resource 자체가 오타로 제대로 생성되지 않았을 경우에도 LookupFailure Exception을 던져서 해석하기 어려웠다.

[org/springframework/boot/autoconfigure/sql/init/DataSourceInitializationConfiguration.class]: Unsatisfied dependency expressed through method 'dataSourceScriptDatabaseInitializer' parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'dataSource' defined in class path resource [org/springframework/boot/autoconfigure/jdbc/JndiDataSourceAutoConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [javax.sql.DataSource]: Factory method 'dataSource' threw exception; nested exception is org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Failed to look up JNDI DataSource with name 'jdbc/mysql'; nested exception is javax.naming.NameNotFoundException: Name [jdbc/mysql] is not bound in this Context. Unable to find [jdbc].

 

@참고(JSP에서 DB연동하기 - JNDI, DBCP 이용): https://all-record.tistory.com/104

블로그 이미지

uchacha

개발자 일지

,

- @참고: https://www.delftstack.com/howto/batch/batch-file-wait-for-command-to-finish/

 

1. Use /WAIT to Wait for a Command to Finish Execution

/B : use to stay in the same process without creating a new window.

cmd /k : used to prevent the command prompt from exiting after execution.

@echo off
echo starting first program
START /B /WAIT cmd /c "C:\Users|Aastha Gas Harda\Desktop\testfile1.bat" > output.txt
echo The first program is executed successfully.
START /B systeminfo >> output.txt
echo ALL the programs are executed successfully
cmd /k

 

2. Use the TIMEOUT Command to Delay the Execution

time -1 : it wil act as a puase command to wait until a key is pressed.

/nobreak : to prevent user keystrokes.

- syntax

TIMEOUT /t <time (sec)>
@echo off
echo starting first program
START /B JRuler.exe
TIMEOUT /t 30
echo The first program is executed successfully.
START /B systeminfo >> output.txt
echo All the programs are executed successfully.
cmd /k

 

3. Use the PAUSE Command to Pause the Execution

puase the execution of a batch file until a key is pressed.

@echo off
echo starting first program
START /B cmd /c "C:\Users\Aastha Gas Harda\Desktop\testfile1.bat" > output.txt
echo The first program is executed successfully.
PAUSE
START /B systeminfo >> output.txt
echo All the programs are executed successfully
cmd /k

'Build' 카테고리의 다른 글

[Gradle] compile vs implementation  (0) 2022.03.14
블로그 이미지

uchacha

개발자 일지

,
블로그 이미지

uchacha

개발자 일지

,

@참고: https://stackoverflow.com/questions/9984223/what-happens-to-git-commits-created-in-a-detached-head-state

 

상황

detached head 상태인줄을 모르고 commit 한 후 다른 branch로 checkout 을 하였으며, commit 내역은 master에 merge 되어야 하는 부분이였다.

 

해결

1. commit 된 hash 값을 확인한다.

$git reflog
HEAD가 참조했던 commit들을 역순으로 보여준다. 특히 "lost" commit 내용도 볼 수 있다.

2. 해당 commit(SHA-1 해쉬값)을 끼고 별개로 새로운 임시 branch를 만든다.

$git branch solve_detach dac3n88

3. 본래 사용하던 branch로 checkout 하여 임시 branch와 merge 한다.

 

블로그 이미지

uchacha

개발자 일지

,

@참고: https://www.manualfactory.net/10147

1. ntp 설치
$yum install ntp

2. 동기화할 서버 주소 세팅
$vi /etc/ntp.conf

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server 0.kr.pool.ntp.org
server 1.asia.pool.ntp.org
server 2.asia.pool.ntp.org
#server 0.centos.pool.ntp.org iburst
#server 1.centos.pool.ntp.org iburst
#server 2.centos.pool.ntp.org iburst
#server 3.centos.pool.ntp.org iburst


3. 방화벽 설정
$firewall-cmd --add-service=ntp --permanent

4. 방화벽 다시 로드
$firewall-cmd --reload

5. ntp 서비스 시작
$systemctl start ntpd

6. ntp 서비스 상태 확인

$systemctl status ntpd

7. 시스템 재부팅 후에도 자동시작하도록 세팅
$systemctl enable ntpd

8. 작동 여부 확인
$ntpq -p

9. 동기화된 시간 확인
$date

블로그 이미지

uchacha

개발자 일지

,

[HikariCP] Configuration

DB 2022. 3. 25. 16:57

- @참고: https://github.com/brettwooldridge/HikariCP#artifacts

 

유용하게 쓰일만한 설정 몇가지를 짚어본다.

 

⏳connectionTimeout

이 property는 client가 pool로부터 connection을 기다리는 최대 miliseconds를 통제한다. 사용 가능한 connection을 받지 못하고 이 시간이 초과되면, SQLException이 thrown 된다.

최소 connection timeout 시간은 250 ms 이다.

Default: 30000 (30 sec)

 

⏳idleTimeout

이 property는 connection이 pool에서 놀게 허용하는 최대 시간을 조정한다.

오직 minimumIdlemaximumPoolSize 보다 작게 정의된 경우에만 적용된다. 

pool size가 minimumIdle과 같아지면 idle connection이 해제 되지 않는다.

연결이 idle(유휴) 상태에서 만료되는지되는 지 여부는 최대 +30초 변동성 및, 평균 +15초의 변동성이 있다. 이 시간 전에는 만료되지 않는다.

값이 0이면 idle connection은 절대 pool에서 제거 되지 않는다.

최소 값은 1000ms(10 sec) 이며, Default: 600000ms(10 min) 이다.

 

⏳keepaliveTime

이 property는 HikariCP가 database 나 network infrastructure에 의해 time out 되지 않게 하기 위해 얼마나 자주 connection을 살리기 위해 시도할 건지를 통제한다.

이 값은 maxLifetime 값보다 작아야 한다. (살아있는지 물으려면 죽기 전이여야 할 것이다.)

"keepalive"은 오직 idle connection에만 발생한다. 

connection이 "keepalive" 시간이 되면, connection은 pool에서 제거 되고, "pinged" 된 후 다시 pool로 반환된다.

"ping"은 다음 중 하나다.

JDBC4의 isValid() 메소드 호출이거나 connectionTestQuery 의 실행이다.

최소 값은 30000ms (30 sec) 이고, 분 단위가 가장 바람직하다. Default: 0 (disabled. 즉, 비활성화되는 값이다.)

 

⏳maxLifetime

이 property는 pool에 있는 connection의 최대 lifetime을 통제한다.

이 값을 세팅하길 강력히 추천하고, database나 infrastructure에서 부과한 connection time limit 보다 몇초 짧아야 한다.

0 값은 infinite lifetime 이며, idleTimeout 에 따른다.

최소 값은 30000ms (30 sec) 이며, Default: 180000 (30 min) 이다.

 

🔢minimumIdle

이 property는 HikariCP가 pool에 유지하는 idle connection의 최소 숫자를 통제한다.

만약 idle connection이 이 값 아래로 떨어지고 pool 의 총 connection 이 maximumPoolSize 미만이면, HikariCP 는 재빨리, 효과적으로 connction을 추가한다.

그러나, 최대 성능과 급증한 요구에 대한 응답을 위해, 이 값을 설정하지 말고, HikariCP가 고정 connection pool을 행하게 하는 걸 추천한다.

기본값: maximumPoolSize 값이다.

 

🔢maximumPoolSize

이 property는 idle 과 사용중인 connection을 통틀어 도달 가능한 최대 pool size를 통제한다. 기본적으로 이 값은 database backend에 대한 실제 connection 의 최대 개수를 결정한다.

합리적인 값은 실행환경에 의해 결정된다.

pool 이 이 사이즈에 도달하고, 사용가능한 idle connection이 없으면, getConnection() 호출은 time out 되기 까지 connectionTimeout milliseconds 만큼 block 된다.

블로그 이미지

uchacha

개발자 일지

,

- @참고: https://docs.docker.com/compose/networking/

 

기본적으로 Compose는 당신의 앱에 단일 network를 세팅한다. 각각의 service에 대한 container는 default network에 합류하고, 각각은 다른 container와 container의 이름과 동일한 hostname으로 통신할 수 있다.

당신의 앱의 network는 "project 명"에 기반한다. 즉, 프로젝트의 directory 명이다. --project-name flag나 COMPOSE_PROJECT_NAME 환경 변수로 override 할 수 있다.

 

예를 들어, 당신의 앱이 myapp 이라는 디렉토리에 있고, docker-compose.yml 이 아래와 같다고 하자.

version: "3.9"
services:
  web:
    build: .
    ports:
      - "8000:8000"
  db:
    image: postgres
    ports:
      - "8001:5432"

docker-compose up 을 하면, 다음과 같은 일이 벌어진다.

1. myapp_default 라는 network가 생성된다.

2. web의 configuration을 사용한 container가 생성되고, myapp_default 라는 network에 합류해서 host명은 web이 된다.

3. db의 configuration을 사용한 container가 생성되고, myapp_default라는 network에 합류해서 host명은 db가 된다.

각 컨테이너는 hostname webdb를 찾을 수 있고, 각각을 올바른 container의 IP address로 돌릴 수 있다. 예를 들어, web의 어플리케이션은 postgres://db:5432 로 연결하고 사용할 수 있다.

** HOST_PORTCONTAINER_PORT 를 구분하는게 중요하다. 위의 예에서, dbHOST_PORT8001 이고 container port는 5432(postgre의 기본값) 이다. service-to-service 네트워크는 CONTAINER_PORT를 쓴다. HOST_PORT 가 정의되면, service는 외부에서 접근 가능하다.

web container 내부에서, db에 접속하는 주소는 postgres://db:5432와 같고, host machine에서 연결 주소는 postgres://{DOCKER_IP}:8001 이다.

서비스 명 외부 접근 주소(DOCKER_IP:HOST_PORT) 외부 접근 주소와 매핑되는 컨테이너 내부 주소(hostname:CONTAINER_PORT)
web {DOCKER_IP}:8000 web:8000
db {DOCKER_IP}:8001 db:5432

 

container 업데이트 시

service에 대한 configuration을 변경하고 docker-compose up 을 하면, 예전 container는 삭제되고 새로운 container가 다른 IP 주소지만 같은 이름으로 생성된다. running container는 그 이름을 찾을 수 있고, 새로운 주소로 연결할 수 있으며, 예전 IP 주소는 동작을 멈춘다.

만약 어떤 컨테이너가 예전 컨테이너로 연결을 열면, 동작하지 않는다. 이러한 조건을 찾고, 이름을 찾고 연결하는게 컨테이너의 책임이다.

서비스 명 외부 접근 주소(DOCKER_IP:HOST_PORT) 외부 접근 주소와 매핑되는 컨테이너 내부 주소(hostname:CONTAINER_PORT)
web {DOCKER_IP}:8000 web:8000 (web에 대한 ip가 변경됨)
db {DOCKER_IP}:8001 db:5432 (db에 대한 ip가 변경됨)

 

Links

Links는 다른 서비스에서 닿을 수 있는 여분의 별칭을 정의할 수 있게 한다. 각 service는 다른 service에 service 이름으로 서로 통신할 수 있으므로, 서비스가 통신하는데 필수값은 아니다. 다음 예에서 dbweb으로부터 hostname dbdatabase로 연결가능하다.

version: "3.9"
services:

  web:
    build: .
    links:
      - "db:database"
  db:
    image: postgres

 

Multi-host networking

Docker Engine에서 Compose application을 Swarm mode enabled 하게 배포하면, multi-host communication을 가능하게 하는 내장 overlay driver를 사용할 수 있다.

Swarm cluster를 구성하는 방법을 보려면, Swarm mode section을 봐라. multi-host overlay networks를 알고 싶으면 Getting started with multi-host networking을 봐라.

 

custom network 구성하기

기본 app network 대신에, top-levelnetworks key로 자신만의 networks를 구성할 수 있다. 더 복잡한 topologies를 생성할수 있게 하고 custom network driver와 options을 구성할 수 있게 한다. Compose 에 의해 관리되지 않는 외부 생성된 network에 연결하기 위해 사용할 수도 있다.

각각의 서비스는 어떤 네트워크가 service-levelnetworks key와 연결될건지 구성할 수 있고, top-level networks key 아래에 언급된 entries의 이름들 리스트이다.

아래는 두 custom network를 정의한 예시 Compose 파일이다. proxy service는 db service와 분리되어 있고, 공통의 network를 공유하지 않는다. 오직 app만 둘다 통신이 가능하다.

version: "3.9"

services:
  proxy:
    build: ./proxy
    networks:
      - frontend
  app:
    build: ./app
    networks:
      - frontend
      - backend
  db:
    image: postgres
    networks:
      - backend

networks:
  frontend:
    # Use a custom driver
    driver: custom-driver-1
  backend:
    # Use a custom driver which takes special options
    driver: custom-driver-2
    driver_opts:
      foo: "1"
      bar: "2"

Networks는 연결된 각 네트워크에 대하여 ipv4_address 또는 ipv6_address 를 세팅함으로써 고정 IP 주소로 구성 가능하다. Networks는 주어진 custom name 으로도 가능하다.(version 3.5부터)

가능한 network configuration option에 대한 자세한 내용을 알려면, 다음을 참조해라.

 

Top-level networks key 중

external

true로 세팅되면, network가 Compose 외부에서 생성되었음을 지정한다. docker-compose up 이 생성하려 하지 않고, 존재하지 않으면 error를 뱉는다. 

3.3이나 그 아래 format에서는, external이 다른 configuration key(driver, driver_opts, ipam, internal)와 함께 사용될 수 없다. v 3.4 이상에서는 그런 제한이 없다.

아래 예시에서는, proxy가 외부와의 gateway이다. [projectname]_outside를 생성하려 시도하는 대신, Compose는 outside라 불리는 network를 찾고, proxy service container를 그 네트워크에 연결한다.

version: "3.9"

services:
  proxy:
    build: ./proxy
    networks:
      - outside
      - default
  app:
    build: ./app
    networks:
      - default

networks:
  outside:
    external: true
!! version 3.5 file format에서 deprecated 된 것
external.name 은 version3.5 file format 부터 사용되지 않고, 대신 name을 사용한다.

Compose file 내에서 언급한 이름과 별도로 network 이름을 지정할 수도 있다.

version: "3.9"
networks:
  outside:
    external:
      name: actual-name-of-network

 

default network 구성하기

따로 network를 구성하는 대신, networks 이름을 default로 두어서 앱 전반에 기본 network를 세팅할 수도 있다.

version: "3.9"
services:
  web:
    build: .
    ports:
      - "8000:8000"
  db:
    image: postgres

networks:
  default:
    # Use a custom driver
    driver: custom-driver-1

 

기존에 존재하는 network를 사용하기

container가 기존 존재하는 network에 합류하길 원하면, external 옵션을 사용해라.

services:
  # ...
networks:
  default:
    external:
      name: my-pre-existing-network

[projectname]_default 의 네트워크를 생성하는 대신, Compose는 my-pre-existing-network를 찾고, 앱의 container와 연결한다.

블로그 이미지

uchacha

개발자 일지

,