Giter Site home page Giter Site logo

nginx's Introduction

NGINX Server Cloud Native Buildpack

The NGINX buildpack provides the NGINX binary distribution. The buildpack installs the NGINX binary distribution onto the $PATH which makes it available for subsequent buildpacks and/or the application image.

The NGINX buildpack is compatible with the following builder(s):

Integration

The NGINX CNB provides nginx as a dependency. Downstream buildpacks, like PHP Web CNB can require the nginx dependency by generating a Build Plan TOML file that looks like the following:

[[requires]]

  # The name of the NGINX dependency is "nginx". This value is considered
  # part of the public API for the buildpack and will not change without a plan
  # for deprecation.
  name = "nginx"

  # The version of the NGINX dependency is not required. In the case it
  # is not specified, the buildpack will provide the default version, which can
  # be seen in the buildpack.toml file.
  # If you wish to request a specific version, the buildpack supports
  # specifying a semver constraint in the form of "1.*", "1.17.*", or even
  # "1.17.9".
  version = "1.17.9"

  # The NGINX buildpack supports some non-required metadata options.
  [requires.metadata]

    # Setting the launch flag to true will ensure that the NGINX
    # dependency is available on the $PATH for the running application. If you are
    # writing an application that needs to run NGINX at runtime, this flag should
    # be set to true.
    launch = true

Usage

To package this buildpack for consumption:

$ ./scripts/package.sh

Data driven templates

The NGINX buildpack supports data driven templates for nginx config. You can use templated variables like {{port}}, {{env "FOO"}} and {{module "ngx_stream_module"}} in your nginx.conf to use values known at launch time.

A usage example can be found in the samples repository under the nginx directory.

PORT

Use {{port}} to dynamically set the port at which the server will accepts requests. At launch time, the buildpack will read the value of $PORT to set the value of {{port}}.

For example, to set an NGINX server to listen on $PORT, use the following in your nginx.conf file:

server {
  listen {{port}};
}

Then run the built image using the PORT variable set as follows:

docker run --tty --env PORT=8080 --publish 8080:8080 my-nginx-image

Environment Variables

This is a generic case of the {{port}} directive described ealier. To use the value of any environment variable $FOOVAR available at launch time, use the directive {{env "FOOVAR"}} in your nginx.conf.

For example, include the following in your nginx.conf file to enable or disable gzipping of responses based on the value of GZIP_DOWNLOADS:

gzip {{env "GZIP_DOWNLOADS"}};

Then run the built image using the GZIP_DOWNLOADS variable set as follows:

docker run --tty --env PORT=8080 --env GZIP_DOWNLOADS=off --publish 8080:8080 my-nginx-image

Loading dynamic modules

You can use templates to set the path to a dynamic module using the load_module directive.

  • To load a user-provided module named ngx_foo_module, provide a modules/ngx_foo_module.so file in your app directory and add the following to the top of your nginx.conf file:
{{module "ngx_foo_module"}}
  • To load a buildpack-provided module like ngx_stream_module, add the following to the top of your nginx.conf file. You do not need to provide an ngx_stream_module.so file:
{{module "ngx_stream_module"}}

Configurations

Specifying the NGINX Server version through buildpack.yml configuration is deprecated and will not be supported in NGINX Server Buildpack v1.0.0.

To migrate from using buildpack.yml please set the following environment variables at build time either directly (ex. pack build my-app --env BP_ENVIRONMENT_VARIABLE=some-value) or through a project.toml file

BP_NGINX_VERSION

The BP_NGINX_VERSION variable allows you to specify the version of NGINX Server that is installed.

BP_NGINX_VERSION=1.21.0

This will replace the following structure in buildpack.yml:

nginx:
  # this allows you to specify a version constraint for the nginx dependency
  # any valid semver constraints (e.g. 1.* and 1.21.*) are also acceptable
  version: "1.21.0"

BP_WEB_SERVER_ENABLE_PUSH_STATE

The BP_WEB_SERVER_ENABLE_PUSH_STATE variable enables push state based routing for Single-page applications relying on browser history API. NGINX Server will send the content at / in response to any requested endpoint. Usefull for React, Angular, Vue and other SPAs.

BP_NGINX_STUB_STATUS_PORT

The BP_NGINX_STUB_STATUS_PORT variable exposes a handful of NGINX Server metrics via the stub_status module which provides basic status information on provided port. This comes handy for monitoring the server. For example using NGINX Prometheus Exporter

nginx's People

Contributors

accrazed avatar arjun024 avatar brayanhenao avatar c0d1ngm0nk3y avatar cf-buildpacks-eng avatar christopherfriedrich avatar dependabot-preview[bot] avatar dependabot[bot] avatar dfreilich avatar dwillist avatar foresteckhardt avatar francescopersico avatar joshuatcasey avatar joshzarrabi avatar kardolus avatar mdelillo avatar mucsi96 avatar paketo-bot avatar robdimsdale avatar ryanmoran avatar sophiewigmore avatar thitch97 avatar tisvictress avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

nginx's Issues

Update module from cloudfoundry -> paketo-buildpacks

The current go.mod file references a github.com/cloudfoundry repo. Now that this repo lives in the paketo-buildpacks org, we should update the module name and the internal import statements in this codebase.

IMPORTANT NOTICE: End of Support for NGINX versions 1.17.x after 2020-08-07

The first release of the NGINX buildpack after 2020-08-07 will no longer include NGINX versions 1.17.x. These NGINX versions will no longer be supported upstream[1]. Please migrate your NGINX apps to supported versions of NGINX before that time.

Note: As 1.17.x is the current default version of NGINX in the buildpack, the default NGINX version will be updated to 1.19.x as a part of this removal. If you’d like to use a different NGINX version, please configure your application to select that version.

Thanks,
Kashyap Vedurmudi, Buildpacks PM

Migrate docs into a Hugo module

In order to locate Paketo documentation closer to the code it documents, we can migrate the docs for this language family from where they currently live in the paketo website repo into a Hugo module that sits inside this repository.

For an example of this, see the Hugo module that sits inside the Paketo Dotnet Core language family repo.

To do this successfully, we need

  • A workflow that automatically tags a release of the docs module when a release is cut on this language family repo. This has been handled in a PR to the centralized Paketo github-config repository
  • A Hugo module inside this language family repo (This module needs to have the name github.com/paketo-buildpacks/<name of this repo>/docs in order for the existing automation to work properly.) It should have the same structure as the Hugo module inside the dotnet-core repo.
  • An additional entry in the go.mod of the paketo-website repo for this repo's docs module
  • An additional [[module.imports.mounts]]in the paketo-website repo's hugo config.toml that mounts the content in this repo's docs module into the proper path in the site's directory structure. That path should match the path to the existing docs file in that repo (Hint: The docs file is probably in here).

Compile dependency on actual stack images

The dependency that this buildpack provides (nginx) is compiled on an image that isn't actually the stack image. This could result in subtle bugs - like features not being enabled or enabled features not being available at run-time - due to differences in configuration and available libraries. We should compile the dependency on the actual stack base image rather than a similar image.

IMPORTANT NOTICE: End of Support for NGINX versions 1.18.x and 1.19.x after 2021-07-05

The first release of the NGINX buildpack after 2021-07-05 will no longer include NGINX versions 1.18.x and 1.19.x. These NGINX versions will no longer be supported upstream. Please migrate your NGINX apps to supported versions of NGINX before that time.

Note: As 1.19.x is the current default version of NGINX in the buildpack, the default NGINX version will be updated to 1.21.x as a part of this removal. If you’d like to use a different NGINX version, please configure your application to select that version.

Thanks,
The Buildpacks Team

Edit: Default version will be 1.21.x, from 1.20.x

Configuring GitBot is recommended

Pivotal provides the GitBot service to synchronize pull requests and/or issues made against public GitHub repos with Pivotal Tracker projects. This service does not track individual commits.

If you are a Pivotal employee, you can configure Gitbot to sync your GitHub repo to your Pivotal Tracker project with a pull request. An ask+cf@ ticket is the fastest way to get write access if you get a 404 to the config repo.

If you do not want have pull requests and/or issues copied from GitHub to Pivotal Tracker, you do not need to take any action.

If there are any questions, please reach out to [email protected].

Implement RFC0038: SBOM

To implement Paketo RFC0038, this buildpack will need to move from storing SBOM information in layer metadata to storing it in files that the CNB lifecycle can manipulate during the build. The RFC outlines what these files are and what they should contain.

Dependabot can't resolve your Go dependency files

Dependabot can't resolve your Go dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

verifying github.com/paketo-buildpacks/[email protected]: checksum mismatch
	downloaded: h1:wHlUTvU6ftwQt202cidSjp0ml2oXYybEP/yRHAQTct8=
	go.sum:     h1:bDixAQpv33yf91eYY/WXJtRwP3LGwwJjCiWUAHjmk3o=

SECURITY ERROR
This download does NOT match an earlier download recorded in go.sum.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

For more information, see 'go help module-auth'.

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

Fail to launch docker image after rebuilding image

What version of Cloud Foundry and CF CLI are you using?

cf 2.141.0
cf-cli 6.44.1+c3b20bfbe.2019-05-08
pack v0.5.0

What version of the buildpack you are using?
latest I assume

If you were attempting to accomplish a task, what was it you were attempting to do?

I'm trying to build a docker image by **pack build** and debug some issues and build again and test.

So steps are;
1. pack build pack --path /where/is/app/
2. docker run --rm -p 8080:8080 -e PORT=8080 pack:latest
3. pack build pack --path /where/is/app/
4. docker run --rm -p 8080:8080 -e PORT=8080 pack:latest

What did you expect to happen?
Rebuilt docker image would be launched fine.

What was the actual behavior?

New docker image doesn't launch with the following error.
Once I remove all previous layers and build again, then it works.
Even there is no change in files.

$docker run --rm -p 8080:8080 -e PORT=8080 pack:latest
ERROR: failed to launch: determine start command: process type web was not found

Can you provide a sample app?
https://github.com/cloudfoundry/nginx-cnb/tree/master/integration/testdata/simple_app

Please confirm where necessary:

  • I have included a log output
  • My log includes an error message
  • I have included steps for reproduction

Use a default port if none is given

Describe the Enhancement

Currently, if users don't set the PORT environment variable when running the application image, they can get an error message that is hard to understand: host not found in "default_server" of the "listen" directive. The primary issue is that the {{port}} interpolation into the template results in an empty field which mangles the directive.

Possible Solution

If the user has not set the PORT environment variable, the {{port}} template function should use a default value like 8080.

Motivation

Doing this would help to streamline the experience for users of the buildpack and reduce the number of environment variables required to run applications using this buildpack.

Container fails to start with read-only file system

What happened?

I want to run the image in read-only mode (docker run --read-only ..) . The start fails.
It seems that 0-configure wants to replace some paths in the nginx.conf which is not possible because the file system is read only.

  • What were you attempting to do?
    Fulfil our security requirements and therefore run in read-only mode.

Immutable (read-only) root filesystem should be enforced for containers

from the Microsoft Azure defender for cloud recommendation reference

  • What did you expect to happen?
    Container is starting correctly.

  • What was the actual behavior? Please provide log output, if possible.
    Start fails with:

failed to create nginx.conf: open /workspace/nginx.conf: read-only file system
ERROR: failed to launch: exec.d: failed to execute exec.d file at path '/layers/paketo-buildpacks_nginx/nginx/exec.d/0-configure': exit status 1

Build Configuration

  • What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
    using? Please include a version.
    pack 0.26.0

  • What buildpacks are you using? Please include versions.
    id = "paketo-buildpacks/nginx"
    version = "0.7.0"

Checklist

  • I have included log output.
  • The log output includes an error message.
  • I have included steps for reproduction.

Appears that `nginx` might not be available on the `$PATH`

What happened?

  • What were you attempting to do?
    Writing a wrapper script around nginx to do something before running the server:

    # set PATH
    export PATH=$PATH:/layers/paketo-buildpacks_nginx/nginx/sbin
    
    cat /workspace/nginx.conf
    
    nginx -p /workspace -c /workspace/nginx.conf
  • What did you expect to happen?
    I expected not to need to set the $PATH.

  • What was the actual behavior? Please provide log output, if possible.
    I needed to set the $PATH so that nginx could be found in my script.

Details come from this blog post.

Checklist

  • I have included steps for reproduction.

Convert into dependency providing buildpack

Convert into dependency providing buildpack

Describe the Enhancement

RFC 0007 has been approved and merged.

Possible Solution

During build the nginx buildpack should only provide its dependency. The nginx buildpack should no longer do any additional configuration. The temporary development build plan API can be removed at this time.

Motivation

This is part of paketo-buildpacks/web-servers#128

Including Service Bindings for nginx.conf and mime.types

What happened?

I would like to inject a nginx.conf file and mime.types from a common location using https://github.com/k8s-service-bindings/spec so that I do not need developers to commit this into source code.

Build Configuration

gcr.io/paketo-buildpacks/nginx:0.3.1

pack and Tanzu Build Service (kpack)

  • Can you provide a sample app or relevant configuration (buildpack.yml,
    nginx.conf, etc.)?

nginx.conf: https://github.com/voor/static-build-service-template/blob/5cfaac6b3b4dec9e5238ea290a866bed52b5c369/nginx.conf
mime.types: https://github.com/voor/static-build-service-template/blob/5cfaac6b3b4dec9e5238ea290a866bed52b5c369/mime.types

Checklist

  • I have included log output.
  • The log output includes an error message.
  • I have included steps for reproduction.

Conform to RFC0043: Reproducible Builds

To conform to RFC0043 this buildpack should ensure that builds are reproducible. Specifically it should not include a built_at metadata field. In the tests that leverage this field to assert layer reuse, we should instead compare layer SHA values across rebuilds.

See also the tracking issue: paketo-buildpacks/rfcs#165.

Support configuring cache-control for index.html when using BP_WEB_SERVER

Before using this buildpack, we use the nginx configuration below to disable cache for index.html:

        # https://stackoverflow.com/a/41635866
        location / {
          try_files $uri $uri/ /index.html;
          gzip_static on;
        }
        location = /index.html {
          add_header cache-control {{ .Values.indexHtmlCacheControl | squote }};
          add_header last-modified '';
          etag off;
        }

it seems this buildpack doesn't provide such option.

Describe the Enhancement

Possible Solution

Motivation

Explicit cache-control for index.html page is more controllable.

Consume Nginx dependency from the dep-server

Per paketo-buildpacks/dep-server#45, we should start consuming the Nginx dependency from the dep-server (https://api.deps.paketo.io/v1/dependency?name=<dependency>) instead of the https://buildpacks.cloudfoundry.org/dependencies/<dependency>/... location we currently get the dependencies from.

This will make the dependency publishing/consumption process more transparent than the process we use for the dependencies available via the dependency-builds pipeline.

We have already done this switch-over in the Node Engine and Yarn Buildpacks. The outline of what this work will entail can be found in the dep-server issue linked at the top.

Support alternative files for nginx config

What happened?

  • What were you attempting to do?

My application has an nginx config file ``application-nginx.confand I don't want to rename it tonginx.conf`. The `application-nginx.conf` follows a company internal convention that makes it easy for us to find configuration files.

  • What did you expect to happen?

I'd expect the buildpack to allow me to provide the configuration file in some manner.

  • What was the actual behavior? Please provide log output, if possible.

Currently, the buildpack does not build an application with an nginx config file named something other than nginx.conf.

I can pack build NGINX apps using packit library

Context
We should re-write the NGINX CNB using packit so that we have improved logging output functionality.

Acceptance Criteria
GIVEN I have an app that uses NGINX
WHEN I pack build it
THEN I can see that packit style logging appears during NGINX detection
AND when I docker run the app it works

Cannot run with custom UID in run image

What happened?

  • What were you attempting to do?
    I'm trying to build a container using the nginx buildpack that can run as a different user than the default CNB user. In order to do so, I've created my own "run image" with a different UID than the default of the CNB user, which I then pass to "pack build" using "--run-image". I've included a Dockerfile for the custom run image below which can be used to reproduce the issue.

  • What did you expect to happen?
    When using the run image with a different UID, I expect the built container to actually start up.

  • What was the actual behavior? Please provide log output, if possible.
    The built container doesn't start up.
    Error message:

docker run -e PORT=8080 my-nginx-app
2022/04/25 06:28:15 [emerg] 1#0: open() "/workspace/logs/nginx.pid" failed (13: Permission denied)

In order to get this to work, I also need a custom 'build image' that changes also the CNB user to the same UID. However, that is annoying since the 'run image' can be specified at build time for the 'pack' executable (--run-image) but the 'build image' cannot. I would need to create a new builder in order to use a different build image.

We deploy to different k8s clusters that require a different UID to run as (which we have no control over), which is why we build several version of our container image with different UIDs. Currently this can be easily done by providing a different --run-image, but if we have to create a new builder everytime, this will become cumbersome.

Note that we have Java apps where we do the same, and for the Java buildpack, no issues occur. The built images can boot on our custom run image without having to modify the build image.

Build Configuration

  • What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
    using? Please include a version.
    pack --version 0.25.0

  • What buildpacks are you using? Please include versions.

Pulling image index.docker.io/paketobuildpacks/builder:full
full: Pulling from paketobuildpacks/builder
Digest: sha256:fec7a2edd24d941fdf73a64a1779163fac36fb14d104a52f906f6ca5169755cd

which uses

paketo-buildpacks/[email protected]

Custom run image:

FROM paketobuildpacks/run:1.3.35-full-cnb

USER root

ARG cnb_uid=2000
ARG cnb_gid=2000

RUN groupmod -g ${cnb_gid} cnb
RUN usermod -u ${cnb_uid} -g ${cnb_gid} cnb
RUN find / -xdev -uid 1000 -exec chown -v -h ${cnb_uid} '{}' \;
RUN find / -xdev -gid 1000 -exec chgrp -v ${cnb_gid} '{}' \;

ENV CNB_USER_ID=${cnb_uid}
ENV CNB_GROUP_ID=${cnb_gid}

USER ${cnb_uid}:${cnb_gid}

So, for completion sake, full steps to reproduce:

# In the nginx-samples directory
pack build my-nginx-app --buildpack paketo-buildpacks/nginx 
docker run -e PORT=8080 my-nginx-app # Works!

# With the run-image being the image built by the above Dockerfile
pack build --run-image custom-run my-nginx-app --buildpack paketo-buildpacks/nginx
docker run -e PORT=8080 my-nginx-app
2022/04/25 06:34:55 [emerg] 1#0: open() "/workspace/logs/nginx.pid" failed (13: Permission denied)

Checklist

  • I have included log output.
  • The log output includes an error message.
  • I have included steps for reproduction.

[Investigate] NGINX binary compiled for debugging

We have received a user request to enable debugging in the NGINX buildpack. This would require recompiling NGINX to include this debugging functionality.

End user goal: this user would like to enable log debugging for their NGINX app

Desired outcomes

  • Level of complexity/effort
  • Identifying both benefits and drawbacks for replacing the current version of NGINX with a debugging-enabled version NGINX.
  • Identifying whether this would change default behavior (i.e. would this be considered a breaking change for the Paketo NGINX buildpack?)

Context: http://nginx.org/en/docs/debugging_log.html

Enable debug logging for all currently supported nginx versions

The nginx buildpack installs nginx without support for debug logging. This change is to ensure that the buildpack installs nginx with support for debug logging, which will require configuring the nginx binaries with the --with-debug option. (According to the nginx docs, prebuilt packages after 1.9.8 include debug logging by default but we compile our binaries from source)

We only want to replace all currently supported versions (2 patches each for 2 version lines = 4 current versions of nginx). We do not want to update any of the previously supported versions.

This issue is to implement what we've learned from #377

This was initially brought up by the commercial team and they have their own story to enable debug logging for nginx. We will need to touch bases with them to ensure they agree with our assessments since this will affect the cloud foundry nginx buildpack.

Upgrade to packit v2

Please upgrade to the latest packit v2 release to enable new features and extended support.

Enable Debug Logging

With the merging of RFC 27 buildpacks should respect the BP_LOG_LEVEL environment variable and allow for debugging logging.

A good example of how to minimally implement this feature can be found in Go Build.

Nginx default etag and last-modified headers not working as expected

Describe the Enhancement

Currently a reproducible build is performed were my image contains my static files of a react front-end application.
Unfortunately, all files modified date at file system level is Jan 01 1980, because all image layers should be reproducible.

Nginx on the other hand uses last modified on file system level to notify clients about changed files. The HTTP headers used are etag and last-modified.

So if I deploy a new image with changed application layer, the client got the old headers and didn't invalidate it's cache.

Possible Solution

I recommend to introduce a flag which enable users of this buildpack to choose whether the original timestamp or 1980 is used for the web server root folder.

Motivation

A useful caching mechanism preserve users of a web application from manually invalidate their cache and therefore increase their experience.

Feature Request: default support for --with-http_v2_module in the buildpack

What version of Cloud Foundry and CF CLI are you using? (i.e. What is the output of running cf curl /v2/info && cf version?
cf version 6.47.1+0921a21b7.2019-10-18
api_version: 2.135.0

What version of the buildpack you are using?
nginx_buildpack-cached-cflinuxfs3-v1.1.1.zip

If you were attempting to accomplish a task, what was it you were attempting to do?
Compiling and loading ngx_http_v2_module as a dynamic module for HTTP2(H2) support.

What did you expect to happen?
Buildpack supports ngx_http_v2_module by default as a static module.

What was the actual behavior?
User manually compiles the HTTP2 module outside of buildpack and loads it to the buidpack by following the steps mentioned under loading modules

Please confirm where necessary:

  • I have included a log output
  • My log includes an error message
Waiting for API to complete processing files...
   Downloading nginx_buildpack...
   Downloaded nginx_buildpack
   Cell 5632a252-5490-4911-8084-4ca986501912 creating container for instance 79a363a3-3753-409f-9480-0074059e8c9c
   Cell 5632a252-5490-4911-8084-4ca986501912 successfully created container for instance 79a363a3-3753-409f-9480-0074059e8c9c
   Downloading app package...
   Downloading build artifacts cache...
   Downloaded app package (905B)
   Downloaded build artifacts cache (7.5M)
   -----> Nginx Buildpack version 1.1.1
   -----> Supplying nginx
   -----> No nginx version specified - using mainline => 1.17.5
   -----> Installing nginx 1.17.5
          Copy [/tmp/buildpacks/959cdfd8a9d869dcf87df7aec864d641/dependencies/23fe53f46ac2476c6effebae0a8d56a1/nginx-1.17.5-linux-x64-cflinuxfs3-fa554ae5.tgz]
   2020/02/21 16:35:33 [emerg] 37#0: dlopen() "/tmp/contents482034713/deps/0/nginx/nginx/modules/ngx_http_v2_module.so" failed (/tmp/contents482034713/deps/0/nginx/nginx/modules/ngx_http_v2_module.so: cannot open shared object file: No such file or directory) in /tmp/conf578605558/nginx.conf:1
   nginx: configuration file /tmp/conf578605558/nginx.conf test failed
          **ERROR** Could not validate nginx.conf: nginx.conf contains syntax errors: exit status 1
   Failed to compile droplet: Failed to run all supply scripts: exit status 14
   Exit status 223
   Cell 5632a252-5490-4911-8084-4ca986501912 stopping instance 79a363a3-3753-409f-9480-0074059e8c9c
   Cell 5632a252-5490-4911-8084-4ca986501912 destroying container for instance 79a363a3-3753-409f-9480-0074059e8c9c
Error staging application: App staging failed in the buildpack compile phase
FAILED

Additional context:
Although, GoRouter doesn't support HTTP/2 connections as mentioned here, HTTP/2 can be achieved through TCP Routing, hence looking to see if we can add the support for http_v2 module by default in the buildpack.

IMPORTANT NOTICE: End of support for nginx versions 1.18.x and 1.19.x effective immediately

Previously, a 30 day notice was sent alerting users of the nginx buildpack that nginx versions 1.18.x and 1.19.x would be removed in July, 2021. It has been recognized that version lines older than 1.20.x of nginx contain a critical CVE and thus, the affected version lines will be removed in the next release of the nginx buildpack; earlier than previously stated.

Additionally, the default version of nginx will become 1.21.x in the next release. We do not anticipate your application to incur breaking changes, but please be ready to ensure your nginx applications are configured to run with the latest nginx versions.

Thanks,
Buildpacks Team

Add support for the tiny stack

What happened?

  • What were you attempting to do?

I want to use the tiny stack with the nginx buildpack, because I want to have a very minimalist image.

  • What did you expect to happen?

nginx would happily run on tiny.

  • What was the actual behavior? Please provide log output, if possible.

'validating buildpack paketo-buildpacks/[email protected]: stack io.paketo.stacks.tiny is not supported'

Build Configuration

apiVersion: kpack.io/v1alpha1
kind: ClusterBuilder
metadata:
  name: node-script-builder
spec:
  order:
  - group:
    - id: paketo-buildpacks/nodejs
    - id: paketo-buildpacks/nginx
    - id: source-removal
  serviceAccountRef:
    name: default
    namespace: default
  stack:
    kind: ClusterStack
    name: tiny #! Make sure tiny is properly loaded from the dependency syncer.
  store:
    kind: ClusterStore
    name: node-cluster-store
  tag: #@ "{}/node-script-builder:0.0.1".format(data.values.docker_repository)
  • What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
    using? Please include a version.

kpack released with Tanzu Build Service 1.2.2

  • What buildpacks are you using? Please include versions.

gcr.io/paketo-buildpacks/nginx:0.3.1

  • What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?

  • Can you provide a sample app or relevant configuration (buildpack.yml,
    nginx.conf, etc.)?

Checklist

  • I have included log output.
  • The log output includes an error message.
  • I have included steps for reproduction.

Add development compatibility API

Add development compatibility API

Describe the Enhancement

RFC 0007 has been approved and merged. This change will help in the development of other buildpacks that are needed to complete the re-architecture. See the tracking issue linked below for more details.

Possible Solution

Create a buildpack that meets the following criteria:

  • Detection
    • Add an or'd provide nignx-development for the initial development period this will be removed once the nignx buildpack has been converted to a dependency providing buildpack.
  • Build
    • Check to see if the provision matched was nginx-development and if so only install the dependency and return.

Motivation

This is part of paketo-buildpacks/web-servers#128

Implement Dependency RFC 0004 for nginx

Implement Dependency Management RFC Phase 1 for nginx. Check out the RFC for more details and background.

1. Determine dependency source strategy

Background

When possible, dependencies should be used directly from upstream, rather than undergoing any additional compilation or modifications performed by Paketo-maintained code. For each dependency, the corresponding buildpack maintainer group will decide if the dependency can be used directly from upstream, and must identify the location from which the dependency will be pulled from. Some of the Paketo Java buildpacks perform directory stripping during the buildpack build process itself. This could be a viable alternative to performing directory modifications during the dependency management process for maintainers to consider.

  • Determine whether the dependency can be used directly from its upstream, rather than undergoing additional compilation/modification.
  • If using directly from upstream, note where dependencies will come from
  • If compiled or modified, note the decision for this
  • Document decision in a language-family level RFC. This decision can be combined in the RFC with the decision made for other buildpacks in the language family.

2. Version retrieval and metadata generation code

Please refer to the retrieval RFC section on version retrieval for details around the API and background.

  • Create retrieval code for the dependency
  • Will live in the buildpack under: dependency/retrieval/
  • Per the RFC, this will be a combination of (1) discovering new dependency versions based on the buildpack.toml, and (2) generating metadata for each new version.
  • Note : Per the RFC caveat - if the dependency is to be compiled, the SHA256 and URI field from the metadata should be omitted in this step.

3. Compilation code (if needed)

If the dependency will be compiled/modified, then refer to the compilation RFC section for API details and background.

  • Create compilation action
  • Will live in the buildpack under: dependency/actions/compile/

4. Dependency testing (optional)

It's up to maintainer discretion if the dependency will be tested. It's recommended to test the dependency if it's been compiled. Check out the testing RFC section for details.

  • Add tests for dependency
  • Will live in the buildpack under: dependency/test.

5. Makefile Setup

When using the generalized workflows for dependency management down the line, version retrieval and dependency testing will be executed via a Makefile in order to provide the workflow a standardized way to run the code, regardless of what language it was written in. Check out the RFC section for what this should look like.

  • Add Makefile
  • Will live in the buildpack at: dependency/Makefile

6. Leveraging the new code

This issue serves to set up all the main logic for the dependency management. The work to actually leverage this code and migrate off of the dep-server will be completed in a separate issue once workflows and infrastructure is set up.

Failing builds as of latest release - CrashLoopBackOff

What happened?

Hello,

Our previously successful builds have been failing since 3/30. We're getting a CrashLoopBackOff in our k8s pods with this error:

open() "/workspace/logs/nginx/error.log" failed (2: No such file or directory)

I'm not an expert on this topic, so please let me know if this belongs elsewhere or needs more clarification.

Build Configuration

  • What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
    using? Please include a version.

We are using pack v0.21.1

  • What buildpacks are you using? Please include versions.
  • What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?

Here is the relevant Cloudbuild stage:

- id: "build-frontend-image"
    name: "gcr.io/k8s-skaffold/pack"
    entrypoint: "/bin/sh"
    dir: "frontend"
    env:
      - "SERVICE=frontend"
      - "BUILDER=base"
      - "STACK=$_STACK"
    args:
      - "-c"
      - |
        pack build gcr.io/$PROJECT_ID/$_REPO-$$SERVICE --publish \
          --cache-image gcr.io/$PROJECT_ID/$_REPO-$$SERVICE:cache \
          --buildpack gcr.io/paketo-buildpacks/nodejs \
          --buildpack gcr.io/paketo-buildpacks/nginx \
          --buildpack gcr.io/paketo-community/staticfile \
          --tag gcr.io/$PROJECT_ID/$_REPO-$$SERVICE:$_BRANCH_NAME_NO_SLASHES_LOWERCASE \
          --tag gcr.io/$PROJECT_ID/$_REPO-$$SERVICE:latest \
          --tag gcr.io/$PROJECT_ID/$_REPO-$$SERVICE:$SHORT_SHA \
          --env "BP_NODE_RUN_SCRIPTS=containerize:$$STACK" \
          --builder paketobuildpacks/builder:$$BUILDER
    waitFor:
      - "-"
  • Can you provide a sample app or relevant configuration (buildpack.yml,
    nginx.conf, etc.)?

This is the contents of buildpack.yml:

staticfile:
  nginx:
    pushstate: true

Any ideas? Thanks!

Chris

Allow location of nginx.conf to be configurable by environment variable

Currently the location of nginx.conf is hard-coded. This buildpack would be more resilient and flexible if this were configurable.

There are a couple of use-cases for this:

  • Upstream buildpacks (e.g. php-nginx) can instruct this buildpack as to where it can find the nginx config file that was created earlier in the build process
  • Application developers can instruct this buildpack as to where their nginx configuration file is, if it is not in the root of their application directory.

I propose the following configuration:

  • This buildpack optionally looks for the environment variable called BP_NGINX_CONF_LOCATION
  • If the environment variable is unset, fall back to the default location of /workspace/nginx.conf
  • If the environment variable is set to a relative filepath, assume that it is relative to /workspace/
  • If the environment variable is set to an absolute filepath, use it as-is (i.e. relative to /

I am happy to move this to an RFC if that process is preferred.

Allow basic auth to be configurable via service binding

Summary

Implement the Basic Authentication configuration settings for Web Servers RFC0004.

Proposal

When a htpasswd type service binding is present, the buildpack should use this binding to configure basic authentication. Check out https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/ for details on how to configure this in nginx.conf.

Outcome

Given an application with no nginx.conf file and a htpasswd service binding, when we run pack build myapp --buildpack paketo-buildpacks/nginx --env BP_WEB_SERVER=nginx --env SERVICE_BINDING_ROOT=/bindings --volume ./my-binding:/bindings/my-binding, then we should see the application can be built and that the static files are served by NGINX behind basic authentication.

Container fails to start with read-only file system #2

I run this buildpack via helm chart and configured my security context like so:

securityContext:
  readOnlyRootFilesystem: true
  runAsNonRoot: true
volumes:
  - emptyDir: {}
    name: tmpdir
podVolumeMounts: 
  - mountPath: /tmp
    name: tmpdir

As the only exception I made /tmp writeable.
Therefore I used an own nginx.conf with some templated values. See:

daemon off;
worker_processes {{env "NGINX_WORKERS"}};
...
http {
  ...
  access_log /dev/stdout;
  error_log stderr;
  client_body_temp_path {{ tempDir }}/client_body_temp;
  proxy_temp_path {{ tempDir }}/proxy_temp;
  fastcgi_temp_path {{ tempDir }}/fastcgi_temp;
  ...
  server {
    listen 8080;
    server_name _;
    client_max_body_size {{env "NGINX_CLIENT_MAX_BODY_SIZE"}}M;
    root ./{{env "NGINX_ROOT"}};
    ...
    location / {
      try_files $uri $uri/ /index.html;
      add_header Last-Modified "{{ env "NGINX_LAST_MODIFIED_HEADER" }}";
      # switch ETag off, since file modification time is always 01-01-1980
      etag off;
    }
  }
}

Expected Behavior

Nginx is up and running serving my content.

Current Behavior

Nginx doesn't start, because configure-0 tries to write on a read-only location.
This was already reported #385

failed to create nginx.conf: open /workspace/nginx.conf: read-only file system
ERROR: failed to launch: exec.d: failed to execute exec.d file at path '/layers/paketo-buildpacks_nginx/nginx/exec.d/0-configure': exit status 1

Possible Solution

In this issue I try to focus on templating issues with nginx.conf. Configure nginx to not write anything should be addressed at nginx team.
Not using templating in nginx.conf was already discussed and is still one workaround. For me this is not an option. E.g. we're using a dynamic URL to proxy our backend depending on our actual environment.

Solutions:

  1. (preferred) Do not perform an replacement of nginx.conf. Instead use the input file as template and write the output file to a user specified location. If BPL_NGINX_CONF_LOCATION is set this configuration is written and used.
  2. A user is responsible to copy nginx.conf to a build/run writeable location e.g. /tmp. Additionally set BP_NGINX_CONF_LOCATION=/tmp/nginx.conf. To make configure-0 working a user must also copy it's nginx.conf at runtime to tmp. Maybe by mounting a ConfigMap to a volume or by other means.

Steps to Reproduce

  1. Deploy an image via helm chart with this values:
securityContext:
  readOnlyRootFilesystem: true
  runAsNonRoot: true

Motivations

As already mentioned we strive to run our images as secure as possible. To do so we try to run a container read-only with some exceptions.
This is described here

Running a read-only file system in your containers forces your containers to be immutable.
Not only does this mitigate some old (and risky) practices such as hot patching, but also helps you prevent the risks of malicious processes storing or manipulating data inside a container.

IMPORTANT NOTICE: [nginx] End of Support for NGINX versions 1.16.x after 2020-06-07

The first release of the NGINX Paketo buildpack after 2020-06-07 will no longer include NGINX versions 1.16.x. These NGINX versions will no longer be supported upstream[1]. Please migrate your NGINX apps to supported versions of NGINX before that time.

Note: As 1.16.x is the current stable version of NGINX in the buildpack, the stable NGINX version will be updated to 1.18.x as a part of this removal. If you’d like to use a different NGINX version, please configure your application to select that version.

As always, the Paketo Buildpacks contributors are happy to answer questions you may have about this deprecation in the Paketo Buildpacks Slack channel[2].

[1] - https://nginx.org/en/download.html
[2] - https://slack.paketo.io

Thanks,
Kashyap Vedurmudi, Buildpacks PM

Allow HTTPS to be enforced via environment variable

Summary

Implement the HTTPS Enforcement configuration settings for Web Servers RFC0004.

Proposal

When the BP_WEB_SERVER_FORCE_HTTPS environment variable is set to true, the buildpack will generate configuration in the nginx.conf file that forces http requests to be redirected to https endpoints. Check out https://github.com/paketo-community/staticfile/blob/7f56d26d8ac7b4b2e17199ace2b944206276027e/server_configs/nginx.conf#L120-L140 for details how this is configured currently in the staticfile buildpack.

Outcome

Given an application with no nginx.conf file, when we run pack build myapp --buildpack paketo-buildpacks/nginx --env BP_WEB_SERVER=nginx --env BP_WEB_SERVER_FORCE_HTTPS=true, then we should see the application can be built and that the static files are served by NGINX with http requests being redirected to https.

Allow the directory served by default to be set via environment variable

Summary

Implement the Static File Location configuration settings for Web Servers RFC0004.

By the default, when the BP_WEB_SERVER environment variable is set to nginx, the buildpack will generate an nginx.conf file that serves the static files located at /workspace/public. We should allow users to change this default value by setting the BP_WEB_SERVER_ROOT environment variable.

Proposal

When the user sets this value, we will change our default from serving /workspace/public to the value the user sets. If this path is absolute, it should be set literally. If the path is relative, it should be assumed to be relative to the /workspace directory.

Outcome

Given an application with no nginx.conf file and static files in the /build directory, when we run pack build myapp --buildpack paketo-buildpacks/nginx --env BP_WEB_SERVER=nginx --env BP_WEB_SERVER_ROOT=./build, then we should see the application can be built and that the static files are served by NGINX.

Generate basic `nginx.conf` file when `BP_WEB_SERVER=nginx`

Summary

Implement the most basic case of Web Servers RFC0004. This case will generate a basic, valid nginx.conf file to be used by the start process when the BP_WEB_SERVER environment variable is set to nginx.

Proposal

We'll need to figure out what the simplest possible nginx.conf file would look like to serve files from a directory. In this case, the default directory should be /workspace/public.

Outcome

Given an application including a /public directory containing a set of static files, and not including an nginx.conf file, when I run pack build myapp --buildpack paketo-buildpacks/nginx --env BP_WEB_SERVER=nginx then I should see the application can be built and that the static files are served by NGINX.

Allow Push State to be enabled via environment variable

Summary

Implement the Push State configuration settings for Web Servers RFC0004.

By the default, when the BP_WEB_SERVER environment variable is set to nginx, the buildpack will generate an nginx.conf file that does not enable push state functionality. We should allow users to change this default value by setting the BP_WEB_SERVER_ENABLE_PUSH_STATE environment variable.

Proposal

When the user sets BP_WEB_SERVER_ENABLE_PUSH_STATE to true, the buildpack will generate an nginx.conf file that has enabled push state. For more details on this, check out https://github.com/paketo-community/staticfile/blob/7f56d26d8ac7b4b2e17199ace2b944206276027e/server_configs/nginx.conf#L144-L148 which is the current implementation of this feature in the staticfile buildpack.

Outcome

Given an application with no nginx.conf file and static files in the /public directory, when we run pack build myapp --buildpack paketo-buildpacks/nginx --env BP_WEB_SERVER=nginx --env BP_WEB_SERVER_ENABLE_PUSH_STATE=true, then we should see the application can be built and that the static files are served by NGINX with push state features enabled.

Allow included files to be templated

What happened?

  • What were you attempting to do?
    I was trying to include some templated values like {{port}} in a file that I was include-ing in my nginx.conf. When my app starts the included file has not be templated and NGINX fails to start.

  • What did you expect to happen?
    I expected that my templated files were generated with the dynamic values they require.

Build Configuration

  • Can you provide a sample app or relevant configuration (buildpack.yml,
    nginx.conf, etc.)?

nginx.conf

worker_processes 1;
include my-file.conf;

my-file.conf

http {
  charset utf-8;
  log_format cloudfoundry 'NginxLog "$request" $status $body_bytes_sent';
  access_log /dev/stdout cloudfoundry;
  default_type application/octet-stream;
  include mime.types;
  sendfile on;

  tcp_nopush on;
  keepalive_timeout 30;
  port_in_redirect off; # Ensure that redirects don't include the internal container PORT - 8080

  server {
    listen {{port}};
    root public;
    index index.html index.htm Default.htm;
  }
}

Checklist

  • I have included steps for reproduction.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.