| FROM rust as build | |
| WORKDIR /build | |
| COPY /src /build/src | |
| COPY /man /build/man | |
| COPY build.rs Cargo.toml /build/ | |
| RUN cargo build --release |
| FROM golang:alpine as build | |
| RUN apk add -U --no-cache git | |
| WORKDIR /build | |
| COPY /core /build/core | |
| COPY /vendor /build/vendor | |
| COPY *.mod *.sum *.go /build/ |
| #!/usr/bin/env bash | |
| set -euo pipefail | |
| [ "${DEBUG:-0}" = "1" ] && set -x | |
| [ -n "${PROJECT_NAME:-}" ] || read -r -p "Project name [wordpress]: " PROJECT_NAME | |
| [ -n "${PROJECT_NAME:-}" ] || PROJECT_NAME="wordpress" | |
| [ -n "${WP_HOME:-}" ] || read -r -p "Website URL [https://localsite.localdomain]: " WP_HOME | |
| [ -n "${WP_HOME:-}" ] || WP_HOME="https://localsite.localdomain" | |
| [ -n "${WP_SITEURL:-}" ] || read -r -p "Wordpress URL [https://localsite.localdomain/wp]: " WP_SITEURL |
| #!/bin/sh | |
| # This will display the wordpress plugin name and version, based on some standard formatting | |
| # in a .php file in each plugin. If the plugin author didn't use this convention, this probably | |
| # won't work... but it works for me. | |
| grep -e "^[ *]*Version:" wp-content/plugins/*/*.php | sed -e 's/wp-content\/plugins\/\(.\+\)\/.*\.php:[ *]*Version:[[:space:]]*\(.*\)$/\1:\2/g' |
If you need to track a package with Composer but it doesn't exist in a repository, you can still manage it with Composer. Simply create a custom repository of type 'package', add it to your required packages, and proceed as normal.
composer.json and add a a block to the 'repositories' array like the following.{
"repositories": [
{
"type": "package",
This document explains what Cognito is and how it works.
This page is partly a summary of the following articles:
| FROM centos:6 | |
| # This works, but don't use yum update, it'll update too many packages | |
| RUN CENTOSVER=`cat /etc/centos-release | grep 'CentOS release' | awk '{print $3}'` ; \ | |
| grep -v mirrorlist /etc/yum.repos.d/CentOS-Base.repo \ | |
| | sed -e 's/^#baseurl=/baseurl=/g' \ | |
| | sed -e "s?baseurl=http://mirror.centos.org/centos/\$releasever/?baseurl=https://vault.centos.org/$CENTOSVER/?g" \ | |
| > /etc/yum.repos.d/CentOS-Base.repo.new ; \ | |
| mv -f /etc/yum.repos.d/CentOS-Base.repo.new /etc/yum.repos.d/CentOS-Base.repo | |
| RUN curl -L -o sudo-patched.rpm https://github.com/sudo-project/sudo/releases/download/SUDO_1_9_5p2/sudo-1.9.5-3.el6.x86_64.rpm | |
| RUN yum install -y sudo && rpm -qi sudo && sudo -V |
This document describes the Standard Operating Procedure for migrating both an EC2 instance and an encrypted RDS database to a different AWS account and region.
For this sample case, there is a single EC2 instance which uses a single MariaDB RDS instance (no read-replica, nothing fancy). But the database is encrypted, so migrating a snapshot is a bit complicated. The end result will be that the newly deployed database instance cannot use a customer-managed KMS. To get around this you'll probably have to use a different method entirely to migrate the database (such as S3 export/import, or a manual SQL dump/import).
| FROM alpine:3.13.5 AS php7 | |
| ENV PHP_VER=7.4 | |
| ENV RUNTIME_USER=www-data | |
| ENV RUNTIME_GROUP=www-data | |
| # Alpine www-data UID/GID is 82 | |
| ARG RUNTIME_UID=82 | |
| ENV RUNTIME_UID=$RUNTIME_UID | |
| ARG RUNTIME_GID=82 | |
| ENV RUNTIME_GID=$RUNTIME_GID |
I use a couple tools to make it easier for me to get work done:
cliv. This installs all my typical Ops tools that aren't packaged
by my Linux distribution. This also allows me to switch versions of any tool at any time, either by specifying a
particular version of a tool, or by pinning a version in a .COMMAND-versions file. No need for tfenv.
terraformsh. This wrapper for Terraform makes it much easier to manage lots of environments and run common Terraform commands. It's simpler than TerraGrunt and still allows me