В статье блога о плане я набросал план миграции базы данных EC2-Classic RDS в VPC. Теперь мы можем выполнить второй шаг плана. Это простой шаг. Хотя мы должны понимать, каковы будут последствия. В вашем случае этот подход может потребовать корректировки!
DNS конечной точки RDS
При создании экземпляра базы данных RDS или кластера баз данных RDS AWS предоставляет вам адреса конечных точек. Эти адреса можно использовать для подключения к базе данных. Вы не можете изменить адрес конечной точки базы данных RDS. Это то, что генерируется AWS и на что вы не можете повлиять.
По плану мы хотим обновить запись DNS при миграции на экземпляр RDS на базе VPC. Чтобы это сработало, нам нужна пользовательская запись DNS. Та, которую мы можем контролировать.
Частная размещенная зона
Часто при развертывании служб внутри VPC имеет смысл использовать частную размещенную зону DNS. Такой подход позволяет нам определить, например, внутреннее DNS-пространство, которое мы можем свободно использовать. С помощью AWS-CDK определить такую размещенную зону очень просто:
class NetworkStack extends Stack {
readonly privateHostedZone: IPrivateHostedZone
constructor(scope: Construct, id: string, props?: StackProps) {
super(scope, id, props);
const vpc = new Vpc(this, 'vpc', {
...
})
this.privateHostedZone = new PrivateHostedZone(this, 'internal', {
vpc: vpc,
zoneName: 'internal',
comment: 'private DNS space for registering services'
});
}
}
Пользовательская DNS-запись для конечной точки базы данных
Теперь, когда у нас есть частная размещенная зона, мы можем определить пользовательскую DNS-запись для базы данных. Эта запись должна использоваться для подключения к базе данных из нашей службы (служб). Таким образом, когда мы изменим запись, приложение будет устанавливать соединения с новой базой данных, запущенной внутри VPC.
new CnameRecord(this, 'database cname record', {
domainName: 'current-classical-database-endpoint',
zone: this.privateHostedZone,
recordName: 'database'
})
После развертывания вышеуказанной конфигурации осталось только обновить конфигурацию нашей службы. Имя хоста базы данных, которое мы задали, теперь должно выглядеть как database.internal. Обратите внимание, что мы все еще подключены к классическому экземпляру RDS без VPC.
Важные соображения
Выбранный нами подход прост. Однако он не лишен недостатков. Основная проблема заключается в том, что обновление DNS не приведет к немедленному подключению всех служб к новой базе данных. Во многих случаях это нормально. Более того, нам нужно убедиться, что клиенты базы данных не кэшируют записи DNS слишком долго.
Если вам нужно, чтобы соединения перемещались к новому экземпляру базы данных более контролируемым образом, это все еще возможно. Развертывания с обновлением конфигурации служб базы данных может быть достаточно. Если такое развертывание невозможно, мы можем внедрить сетевой прокси, например, используя сетевой балансировщик нагрузки, ProxySQL или HAProxy.
Петр Мионсковски, руководитель группы, технологический евангелист @ Bright Inventions