| DATABASE_URL=postgres://saleor:password@db/saleor | |
| DEFAULT_FROM_EMAIL=noreply@domain.com | |
| CELERY_BROKER_URL=redis://redis:6379/1 | |
| JAEGER_AGENT_HOST=jaeger | |
| SECRET_KEY=secret_key | |
| API_URI=https://saleor-api.domain.com/graphql/ | |
| ALLOWED_HOSTS=saleor-api.domain.com,saleor-mail.domain.com,saleor-store.domain.com,saleor-admin.domain.com,saleor-jaeger.domain.com | |
| ALLOWED_CLIENT_HOSTS=saleor-api.domain.com,saleor-mail.domain.com,saleor-store.domain.com,saleor-admin.domain.com,saleor-jaeger.domain.com |
| FROM php:7.1-fpm-alpine | |
| RUN apk add --update \ | |
| autoconf \ | |
| g++ \ | |
| libtool \ | |
| make \ | |
| && docker-php-ext-install mbstring \ | |
| && docker-php-ext-install mysqli \ |
| RUN apt update | |
| RUN apt upgrade -y | |
| RUN apt install -y apt-utils | |
| RUN a2enmod rewrite | |
| RUN apt install -y libmcrypt-dev | |
| RUN docker-php-ext-install mcrypt | |
| RUN apt install -y libicu-dev | |
| RUN docker-php-ext-install -j$(nproc) intl | |
| RUN apt-get install -y libfreetype6-dev libjpeg62-turbo-dev libpng12-dev | |
| RUN docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/ |
| # | |
| # Building V8 for alpine is a real pain. We have to compile from source, because it has to be | |
| # linked against musl, and we also have to recompile some of the build tools as the official | |
| # build workflow tends to assume glibc by including vendored tools that link against it. | |
| # | |
| # The general strategy is this: | |
| # | |
| # 1. Build GN for alpine (this is a build dependency) | |
| # 2. Use depot_tools to fetch the V8 source and dependencies (needs glibc) | |
| # 3. Build V8 for alpine |
Transforming elements can be interesting if you're a library author, but can also be very valuable when writing components to abstract behaviour in your existing code base.
To get a better understanding, we will walkthrough the most important React Top Level API transformation functionalities. React offers a couple of helper functions that we can leverage when for creating and adapting elements, further information is available via the official React documentation.
| #!/bin/bash | |
| # https://www.nginx.com/resources/wiki/start/topics/tutorials/install/ | |
| # Switch to root | |
| sudo su | |
| # Add the mainline release | |
| echo "deb http://nginx.org/packages/mainline/ubuntu/ xenial nginx | |
| deb-src http://nginx.org/packages/mainline/ubuntu/ xenial nginx" > /etc/apt/sources.list.d/nginx.list |
One of the best ways to reduce complexity (read: stress) in web development is to minimize the differences between your development and production environments. After being frustrated by attempts to unify the approach to SSL on my local machine and in production, I searched for a workflow that would make the protocol invisible to me between all environments.
Most workflows make the following compromises:
Use HTTPS in production but HTTP locally. This is annoying because it makes the environments inconsistent, and the protocol choices leak up into the stack. For example, your web application needs to understand the underlying protocol when using the secure flag for cookies. If you don't get this right, your HTTP development server won't be able to read the cookies it writes, or worse, your HTTPS production server could pass sensitive cookies over an insecure connection.
Use production SSL certificates locally. This is annoying
| openssl genrsa -out key.pem 2048 | |
| #OR if you want encrypted ca | |
| openssl genrsa -de3 -out key.pem 2048 |
| openssl genrsa -out key.pem 2048 | |
| # OR | |
| openssl genrsa -des3 -out rootCA.key 2048 |
My main development workstation is a Windows 10 machine, so we'll approach this from that viewpoint.
Recently, Google Chrome started giving me a warning when I open a site that uses https and self-signed certificate on my local development machine due to some SSL certificate issues like the one below:
