Summary
The main idea is to solve the problem. Of course, there are as detailed steps as possible. Interested children's shoes can be practiced step by step. Because of the operation and maintenance profession, it is basically the accident as a story to write, I hope I can like it.
origin
For at least 10 years, I haven't played Tomcat on the front line. This time, there's an encounter at the customer site. Although the client said that he would build the project, but the progress of the project is not waiting for people, or do it yourself. Of course, the new server needs to go through the process of application, only the existing server can think of ways. Remembering that Tomcat deployment was a piece of cake, I didn't expect that in the harsh business environment, there were pits everywhere and there were thunderous steps. Nevertheless, we have done development and operation and maintenance, which is not enough to send an email for rescue. Dry!
The server is on the intranet and can be accessed by a thin terminal. MacBook can only access the external network, while looking up information, compared with doing in the intranet, the effect is not good, always worried about the existing environment to be rectified: development and testing there is no fun. As we all know, servers always go directly to the root account. Everyone who has worked in operations and maintenance knows never to touch root. ()Ah, occupational diseases, or careful.
We can only adjust the method: first, we build a single machine multi-instance on MacBook, and then go to the intranet server to do it after verification. What was planned to be completed in 20-30 minutes took only half a day to verify the scheme. When the Intranet was implemented, it encountered harsh environmental constraints and gradually demined, and finally it was finalized. Customer satisfaction, project progress happy.
thinking
According to the actual environment, determine the direction of problem solving: single machine with multiple instances; give up the Dangerous Attempt of intranet: can not be solved quickly and effectively, and account authority is too large; select the external network verification scheme and then enter the intranet for implementation. In many cases, choices outweigh efforts.
Let's simplify the problem first.
Write a validation file and pack it into a war package. Why not use existing code? One reason is that the existing war packages are on the intranet, the other is that they are too complex. In addition, the problem can not be ruled out whether it is the code itself or the way we deploy it, or the problem of the intranet and extranet network environment, or RPWT.
For verification schemes, when solving problems, simplify as much as possible, throw away all external things, and only verify the core. The scheme is validated, and then the actual war package validation is introduced. This is consistent with the guiding ideology of object-oriented programming: abstracting the core things, focusing on one place at a time, not all-round attack. People, after all, have limited energy.
As for why Tomcat 7 is used, it's nothing. Clients only allow this version here.
Release the arrangement before the scheme
2017.8.8Update:
Has commit to docker hub, anxious children's shoes on their own
docker pull aninputforce/tomcat7-ins
Final plan
This is not the way to diagnose the problem, but the way to sort out the overall plan after the final solution. This order is neat. It is enough to have a tight basic time for children's shoes to look at this directly. Children's shoes with time can see the text, running through the thinking of problem analysis and problem solving.
# Simplification: Modeling First - Host Editor - > JDK7 dozen war packages - > Tomcat Default Configuration - > Single Instance - > Single Instance and Double Instance
├── # docker builds jdk7 initial environment: a war package for validation
│ ├── docker search jdk7
│ ├── docker pull codenvy/jdk7
│ ├── docker run --name jjj codenvy/jdk7 /bin/bash
│ ├── java -version && mkdir ~/web && ls ~/ && exit # Mirror container environment works well, create working directory, exit
│ ├── mkdir ~/prms001 ~/prms002 # Host computer
│ ├── # Edit prms001/index.htm and prms002/index.htm
│ ├── docker cp prms001 jjj:/home/user/web && docker cp prms002 jjj:/home/user/web
│ ├── docker exec -it jjj /bin/bash # Container entry
│ ├── sudo chown -R user:user prms001 prms002 Change group
│ ├── cd ~/web/prms001 && jar -cvf prms001.war ./* && ls -la
│ ├── cd ~/web/prms002 && jar -cvf prms002.war ./* && ls -la && exit
│ ├── docker cp jjj:/home/user/web/prms001/prms001.war ~/.
│ ├── docker cp jjj:/home/user/web/prms002/prms002.war ~/.
│ └── docker rm jjj # Exit Container, jdk7 Container Mission Ended
├── # docker builds Tomcat 7 initial environment: used to deduce single machine multi-instance
│ ├── # docker pulls Tomcat 7 image
│ ├── # Start a tomcat container named www
│ │ ├── ./startup.sh # Start web Services
│ │ ├── curl localhost:8080 # Normal visit
│ │ ├── ./shutdown.sh # Stop web Services
│ │ └── # Build the first example
│ │ ├── mkdir tom-ins001
│ │ ├── mv work tom-ins001/ && mv conf/ tom-ins001/ mv logs/ tom-ins001/
│ │ ├── mv temp/ tom-ins001/ && mv webapps/ tom-ins001/
│ │ ├── export CATALINA_BASE=$CATALINA_HOME/tom-ins001/
│ │ ├── sh $CATALINA_HOME/bin/startup.sh -Dcatalina.base
│ │ ├── curl localhost:8080 # Normal visit
│ │ └── exit && docker commit www mytomcat:latest && docker rm www # Container www Mission Ended
│ └── docker run --name web -it -p 8080:8080 -p 80:80 mytomcat /bin/bash # Start a new container
│ ├── # Start the first instance
│ │ ├── export CATALINA_BASE=$CATALINA_HOME/tom-ins001/
│ │ ├── sh $CATALINA_HOME/bin/startup.sh -Dcatalina.base
│ │ └── curl localhost:8080 # Normal visit
│ └── # Build and start the second instance
│ ├── cp -r tom-ins001/ tom-ins002
│ ├── # Edit three ports of tom-ins002/conf/server.xml to avoid conflicts with Example 1.
│ │ ├── Server port="8001", Connector port="80" protocol="HTTP/1.1"
│ │ ├── Connector port="8002" protocol="AJP/1.3"
│ │ ├── docker cp www:/usr/local/tomcat/conf/server.xml .
│ │ ├── vi server.xml
│ │ └── docker cp ./server.xml www:/usr/local/tomcat/conf/
│ └── # Start a new container startup instance 2
│ ├── export CATALINA_BASE=$CATALINA_HOME/tom-ins002/
│ ├── sh $CATALINA_HOME/bin/startup.sh -Dcatalina.base
│ ├── curl localhost:80 # Normal visit
│ ├── exit && docker commit web mytomcat:latest
│ └── docker rm web # End of Container web Mission
└── # Show two examples of single machine:
├── # Configuration Instance 2 Root Directory Running
│ ├── docker run --name web -d -it -p 8080:8080 -p 80:80 mytomcat /bin/bash # Start a new container
│ ├── docker exec -it web /bin/bash
│ ├── cd /usr/local/tomcat/tom-ins002/webapps && tar cvf rootbak.tar ./ROOT/*
│ ├── cd ROOT && rm -rf * # Clear the ROOT directory
│ ├── mkdir /usr/local/tomcat/myapps && exit # Create instance 2war package to store directory, exit container
├── # Deploy the war package of instance 1 and 2 to start validation
│ ├── # Edit ROOT.xml, configure the war package of instance 2 to the / usr/local/tomcat/tom-ins002/ROOT directory
│ ├── docker cp ~/ROOT.xml web:/usr/local/tomcat/tom-ins002/conf/Catalina/localhost
│ ├── docker cp ~/prms002.war web:/usr/local/tomcat/myapps
│ └── docker cp ~/prms001.war web:/usr/local/tomcat/tom-ins001/webapps
├── docker exec -it web /bin/bash
│ ├── export CATALINA_BASE=$CATALINA_HOME/tom-ins001/
│ ├── sh $CATALINA_HOME/bin/startup.sh -Dcatalina.base
│ ├── curl localhost:8080 # Access Normal: Hello from Tomcat instance 001
│ ├── export CATALINA_BASE=$CATALINA_HOME/tom-ins002/
│ ├── sh $CATALINA_HOME/bin/startup.sh -Dcatalina.base
│ └── curl localhost # Access Normal: Hello from Tomcat instance 002
└── # Host Verification
├── curl localhost:8080 # Access Normal: Hello from Tomcat instance 001
├── curl localhost # Access Normal: Hello from Tomcat instance 002
└── exit && docker commit web mytomcat:latest # Exit, submit container change to mirror, validate;The following begins the story:
External Network Verification Scheme
Ten years ago, to learn Java, just build an environment, you can exhaust 90% of the enthusiasm of new people. Give up the intranet attempt, switch to the external network to verify the scheme first, I also had a slight ideological struggle, but on second thought, with the Docker artifact, it will calm down.
Before you start, list the customer's requirements.
- Deploy the new instance as the UAT test environment, but the new server is not yet available
- Root directory, don't take Project path.
- Let's use port 80. You also use 8080 for development and testing.
requirement analysis
The encounter with the wall in the intranet is not without some results, at least straightening out the direction:
- The direction of the scheme is single machine and multiple instances.
- Server is deployed in the root directory
- Don't let the user knock on the port.
At first, we deduce the multi-instance scheme of tomcat.
For docker environment setup, please refer to the official documentation. A link is attached to another of my notes: Docker's first intimate contact Please add a link description
Build the first instance on Docker
Prepare to pull out the mirror
docker pull tomcat:7.0
Start and run tomcat
Container name www, port 8080:
ChinaDreams:work-diary kangcunhua$ docker run --name www -it -p 8080:8080 tomcat:7.0 /bin/bash root@4b8f58d2cd64:/usr/local/tomcat# cd bin root@4b8f58d2cd64:/usr/local/tomcat/bin# java -version java version "1.7.0_131" OpenJDK Runtime Environment (IcedTea 2.6.9) (7u131-2.6.9-2~deb8u1) OpenJDK 64-Bit Server VM (build 24.131-b00, mixed mode) root@4b8f58d2cd64:/usr/local/tomcat/bin# ./startup.sh root@4b8f58d2cd64:/usr/local/tomcat/bin# ps -ef | grep java root@4b8f58d2cd64:/usr/local/tomcat/logs# tail -f catalina.out root@4b8f58d2cd64:/usr/local/tomcat/logs# curl localhost:8080
Viewing the java process, checking the log is normal, visiting http://localhost:8080 is normal, proving that the mirror and container can work properly.
Build the first example
root@4b8f58d2cd64:/usr/local/tomcat# mkdir tom-ins001 root@4b8f58d2cd64:/usr/local/tomcat# ls LICENSE RELEASE-NOTES bin include logs native-jni-lib tom-ins001 work NOTICE RUNNING.txt conf lib myapps temp webapps root@4b8f58d2cd64:/usr/local/tomcat# mv work tom-ins001/ root@4b8f58d2cd64:/usr/local/tomcat# mv conf/ tom-ins001/ root@4b8f58d2cd64:/usr/local/tomcat# mv logs/ tom-ins001/ root@4b8f58d2cd64:/usr/local/tomcat# mv temp/ tom-ins001/ root@4b8f58d2cd64:/usr/local/tomcat# mv webapps/ tom-ins001/ root@4b8f58d2cd64:/usr/local/tomcat# ls LICENSE NOTICE RELEASE-NOTES RUNNING.txt bin include lib myapps native-jni-lib tom-ins001 root@4b8f58d2cd64:/usr/local/tomcat# cd tom-ins001/ root@4b8f58d2cd64:/usr/local/tomcat/tom-ins001# ls conf logs temp webapps work root@4b8f58d2cd64:/usr/local/tomcat/tom-ins001# echo $CATALINA_HOME /usr/local/tomcat root@4b8f58d2cd64:/usr/local/tomcat/tom-ins001# export CATALINA_BASE=$CATALINA_HOME/tom-ins001/ root@4b8f58d2cd64:/usr/local/tomcat/tom-ins001# sh $CATALINA_HOME/bin/startup.sh -Dcatalina.base root@4b8f58d2cd64:/usr/local/tomcat/tom-ins001# ps -ef | grep java root@4b8f58d2cd64:/usr/local/tomcat/tom-ins001# tail -f catalina.out root@4b8f58d2cd64:/usr/local/tomcat/tom-ins001# curl localhost:8080
Start successfully, host access http://localhost:8080 normal
Submit changes to mirror backup
root@4b8f58d2cd64:/usr/local/tomcat/tom-ins001# exit ChinaDreams:~ kangcunhua$ docker commit www mytomcat:latest
Build a second example
Start the new container and start the first instance
Based on the newly submitted image, a new container is opened. Start instance 1 to verify normal
ChinaDreams:~ kangcunhua$ docker run --name web -it -p 8080:8080 -p 80:80 mytomcat /bin/bash root@c8cc5f309d18:/usr/local/tomcat/tom-ins001# export CATALINA_BASE=$CATALINA_HOME/tom-ins001 root@c8cc5f309d18:/usr/local/tomcat/tom-ins001# sh $CATALINA_HOME/bin/startup.sh -Dcatalina.base root@c8cc5f309d18:/usr/local/tomcat/tom-ins001# ps -ef | grep java root@c8cc5f309d18:/usr/local/tomcat/tom-ins001# tail -f catalina.out root@c8cc5f309d18:/usr/local/tomcat/tom-ins001# curl localhost:8080
Generate the second instance directory
root@c8cc5f309d18:/usr/local/tomcat# cp -r tom-ins001/ tom-ins002 root@c8cc5f309d18:/usr/local/tomcat# ls LICENSE NOTICE RELEASE-NOTES RUNNING.txt bin include lib myapps native-jni-lib tom-ins001 tom-ins002 root@c8cc5f309d18:/usr/local/tomcat# cd tom-ins002 root@c8cc5f309d18:/usr/local/tomcat/tom-ins002# ls conf logs temp webapps work root@c8cc5f309d18:/usr/local/tomcat/tom-ins002# cd .. root@c8cc5f309d18:/usr/local/tomcat# cd tom-ins001/ root@c8cc5f309d18:/usr/local/tomcat/tom-ins001# ls conf logs temp webapps work
Edit server.xml
It mainly modifies three ports to avoid collision with instance 1 port.
- Server port="8001"
- Connector port="80" protocol="HTTP/1.1"
- Connector port="8002" protocol="AJP/1.3"
<?xml version='1.0' encoding='utf-8'?> <Server port="8001" shutdown="SHUTDOWN"> <!-- Unmodified content is omitted here. --> <Service name="Catalina"> <Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /> <Connector port="8002" protocol="AJP/1.3" redirectPort="8443" /> <!-- Unmodified content is omitted here. --> </Service> </Server>Edit ROOT.xml
The purpose is to specify a war package that is not in the webapps directory and automatically decompresses it into the webapps ROOT directory when deployed.
<?xml version="1.0" encoding="UTF-8"?> <Context path="/prms" docBase="/usr/local/tomcat/myapps/prms002.war"></Context>
View cp on tomcat container web
ChinaDreams:~ kangcunhua$ docker cp ~/ROOT.xml www:/usr/local/tomcat/tom-ins002/conf/Catalina/localhost ChinaDreams:~ kangcunhua$ docker exec -it www /bin/bash root@4b8f58d2cd64:/usr/local/tomcat# cd conf/Catalina/localhost/ root@4b8f58d2cd64:/usr/local/tomcat/conf/Catalina/localhost# ls ROOT.xml root@4b8f58d2cd64:/usr/local/tomcat/conf/Catalina/localhost# more ROOT.xml <?xml version="1.0" encoding="UTF-8"?> <Context path="/prms" docBase="/usr/local/tomcat/myapps/prms002.war"></Context> root@4b8f58d2cd64:/usr/local/tomcat/conf/Catalina/localhost# pwd /usr/local/tomcat/conf/Catalina/localhost
Document ownership is wrong, change
root@4b8f58d2cd64:/usr/local/tomcat/conf/Catalina/localhost# ls -al total 12 drwxr-xr-x 2 root root 4096 Jul 31 05:58 . drwxr-xr-x 3 root root 4096 Jul 31 04:23 .. -rw-r--r-- 1 502 dialout 111 Jul 31 05:56 ROOT.xml root@4b8f58d2cd64:/usr/local/tomcat/conf/Catalina/localhost# chown root:root ROOT.xml root@4b8f58d2cd64:/usr/local/tomcat/conf/Catalina/localhost# ls -la total 12 drwxr-xr-x 2 root root 4096 Jul 31 05:58 . drwxr-xr-x 3 root root 4096 Jul 31 04:23 .. -rw-r--r-- 1 root root 111 Jul 31 05:56 ROOT.xml
Make a war deployment package
Reporting errors with war packages
In the tomcat container, it was found that the jar command could not be found.
root@4b8f58d2cd64:/usr/local/tomcat/webapps/examples# jar -cvf prms.war ./* bash: jar: command not found
Building jdk7 environment
There is no local java environment. Decisively build a docker
ChinaDreams:~ kangcunhua$ docker search jdk7 ChinaDreams:~ kangcunhua$ docker pull codenvy/jdk7 ChinaDreams:~ kangcunhua$ docker run --name jjj -it codenvy/jdk7 /bin/bash user@b040d98042c0:/$ java -version user@b040d98042c0:/$ jar user@b040d98042c0:/$ mkdir ~/web && ls ~/ && exit Create a working directory, exit
The host edits the code cp to the container and punches the jar package
ChinaDreams:~ kangcunhua$ mkdir ~/prms001 ~/prms002 ChinaDreams:~ kangcunhua$ vi ~/prms001/index.html ChinaDreams:~ kangcunhua$ vi ~/prms002/index.html ChinaDreams:~ kangcunhua$ docker cp prms001 jjj:/home/user/web && docker cp prms002 jjj:/home/user/web ChinaDreams:~ kangcunhua$ docker exec -it jjj /bin/bash Container entry user@b040d98042c0:~/web$ sudo chown -R user:user prms001 prms002 Change group user@b040d98042c0:~/web$ cd ~/web/prms001 && jar -cvf prms001.war ./* && ls -la user@b040d98042c0:~/web$ cd ~/web/prms002 && jar -cvf prms002.war ./* && ls -la && exit ChinaDreams:~ kangcunhua$ docker cp jjj:/home/user/web/prms001/prms001.war ~/. ChinaDreams:~ kangcunhua$ docker cp jjj:/home/user/web/prms001/prms002.war ~/. ChinaDreams:~ kangcunhua$ docker rm jjj Exit the container. jdk7 End of Container Mission
vi ~/prms001/index.html
<html>
<head>
<meta charset="UTF-8" >
<title> Tomcat instance 1</title>
</head>
<body>
<h1> Hello from Tomcat instance 1</h1>
</body>
</html>vi ~/prms002/index.html
<html>
<head>
<meta charset="UTF-8" >
<title> Tomcat instance 2</title>
</head>
<body>
<h1> Hello from Tomcat instance 2</h1>
</body>
</html>Start instance 1, instance 2
Back to the tomcat container
root@c8cc5f309d18:/usr/local/tomcat# export CATALINA_BASE=$CATALINA_HOME/tom-ins001 root@c8cc5f309d18:/usr/local/tomcat# sh $CATALINA_HOME/bin/startup.sh -Dcatalina.base root@c8cc5f309d18:/usr/local/tomcat# curl localhost:8080 Access Normal root@c8cc5f309d18:/usr/local/tomcat# export CATALINA_BASE=$CATALINA_HOME/tom-ins002/ root@c8cc5f309d18:/usr/local/tomcat# sh $CATALINA_HOME/bin/startup.sh -Dcatalina.base root@c8cc5f309d18:/usr/local/tomcat# curl localhost:80 Access Normal
An exciting moment
Submitting Mirrors and Deleting Old Container web
docker commit web mytomcat:latest && docker rm web
Start a new container named web based on the latest image
docker run --name web -it -p 8080:8080 -p 80:80 mytomcat /bin/bash
Host access
http://localhost/ Access Normal: Hello from Tomcat instance 001.
http://localhost:8080 Access Normal: Hello from Tomcat instance 002.
Single-machine multi-instance scheme passed locally
Programme supplement
Start command
export CATALINA_BASE=$CATALINA_HOME/tom-ins001 && sh $CATALINA_HOME/bin/startup.sh -Dcatalina.base export CATALINA_BASE=$CATALINA_HOME/tom-ins002 && sh $CATALINA_HOME/bin/startup.sh -Dcatalina.base
Stop order
export CATALINA_BASE=$CATALINA_HOME/tom-ins001 && sh $CATALINA_HOME/bin/shutdown.sh -Dcatalina.base export CATALINA_BASE=$CATALINA_HOME/tom-ins002 && sh $CATALINA_HOME/bin/shutdown.sh -Dcatalina.base
Troubleshooting command
ps -ef | grep java kill -9 xxx tomcat Instance process number tail -f $CATALINA_HOME/tom-ins001/logs/catalina.out tail -f $CATALINA_HOME/tom-ins002/logs/catalina.out curl localhost:8080/prms001/ curl localhost
Directory structure reference
The most critical elements are retained:
.
├── bin
├── lib
├── myapps
│ └── prms002.war
├── tom-ins001
│ ├── conf
│ │ └── server.xml
│ ├── logs
│ │ └── catalina.out
│ ├── webapps
│ │ ├── prms001
│ │ └── prms001.war
│ └── work
└── tom-ins002
├── conf
│ ├── Catalina
│ │ └── localhost
│ │ └── ROOT.xml
│ └── server.xml
├── logs
├── temp
├── webapps
│ └── ROOT
│ ├── META-INF
│ │ └── MANIFEST.MF
│ └── index.htm
└── workSubmit to docker hub
update: 2017.8.8
ChinaDreams:work-diary kangcunhua$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE mytomcat latest 3f6c6cce5355 7 days ago 370MB ChinaDreams:work-diary kangcunhua$ docker tag 3f6c6cce5355 aninputforce/tomcat7-ins:latest ChinaDreams:work-diary kangcunhua$ docker push aninputforce/tomcat7-ins ChinaDreams:work-diary kangcunhua$ docker push aninputforce/tomcat7-ins:1.0 ChinaDreams:work-diary kangcunhua$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE mytomcat latest 3f6c6cce5355 7 days ago 370MB aninputforce/tomcat7-ins 1.0 3f6c6cce5355 7 days ago 370MB aninputforce/tomcat7-ins latest 3f6c6cce5355 7 days ago 370MB
Intranet Playing: Cruel Business Environment
Everything went smoothly until it hit port 80...
smoothly
Building Example 1
After backup, build instance 1 to ensure that the original application can work properly.
Building Example 2
Stop instance 1 to ensure that instance 2 runs by default.
Root directory deployment instance 2
Edit server.xml, ROOT.xml, empty the ROOT directory, create a new myapps directory, copy the war package into it;
curl http://localhost Access on web server is normal.
LAN access, http://10.29.11.23 No Yes! Visit! Ask!!!
Pit: Suse accesses port 80
Example 2 needs to use port 80. Blocked.
Pit +: No restrictions. We need customer information, but we can't trust it all. As the client said, "We have no restrictions on ports." Do not blindly believe what customers say, but believe in scientific investigation.
As the architect's PC God said, linux defaults that only root users can access port 80. At that time, I always had a question. How did we solve the problem of using port 80 in web server? I remember consulting a PC teacher, but unfortunately the course was tight at that time, although listening to the clouds and mists, I was not ashamed to ask more questions, let alone practice myself offline. Until this time, we had a crop in the customer's field.
We have root account for developing test environment, but we can't deploy web server with root. It's too unprofessional. In the Reboot alumni group, we consulted all the children's shoes cheekily, and got the solution quickly: we can forward all the access of 80 ports to 8081; 8081 is the access port of tomcat instance 2 that we can configure, which is authorized by ordinary users.
Revision of IPtables policy to forward 80-port requests
When I first checked the firewall, I saw that port 80 was open. Deployment machine can access, LAN can not be opened: all access for port 80, forward to 8081.
[root@tomcat7conf]# iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8081
Using port 8081
The server.xml of tomins-002 has been modified, which is still accessible on the deployment machine and the local area network can not be opened.
Check firewalls
Configure 8081 port, restart firewall, deployer access is normal, LAN open is normal
Find FW_SERVICES_EXT_TCP, plus port 8081
[root@tomcat7conf]# vi /etc/sysconfig/SuSEfirewall2 [root@tomcat7conf]# rcSuSEfirewall2 restart
Switch to Tomcat user, restart tomcat, LAN access is normal.
Pits: mature platforms also have hard coding
Find the link on the system home page, though configured with "", but click back to the project path. After searching for the files, it is found that the hard code is written in two js files of the development platform. It should be hard-coded when the platform generates code automatically, instead.
Pit: Mature products are not without Bug
It was found that uniform authentication would cause errors as long as root directory access was configured. Without unified authentication access, normal access can be achieved. Feedback to customers and coordinate solutions;
Hang for two days, there was no feedback, chasing the rush, the only answer is: mature products, we should not doubt the unified certification platform.
I'm so hot-tempered, I'll check with the engineer right away. Step by step, we find that when we submit unified authentication, we need to pass a parameter ssotarget. After authentication, the browser will open the home page. The context-path is not empty, the url is normal, and the context-path is null. That is to say, when we deploy to the root directory, ssotarget only one "/". Check the Unified Authentication Access Logic and find that it uses the filter provided by the platform, decompilation, one-step tracking, and discovers that ssotarget comes from the assignment of homepage. Pinch your nose and look at the source code. As a matter of fact, there are some problems in the logic of the code. The pseudo-algorithm is as follows:
String ccontext_path=request.getContextPath(); // Get the web service context String urlt = requerst.getRequestURL(); // Get the full web address requested String cwebhost = urlt.substring(0, urlt.IndexOf (context-path)); // Get http://hostname:port homepage = webhost + context_path + "/"; // Spell out the application home page address of web server
Change it
String context_path = request.getContextPath(); String homepage = request.getScheme()+"://"+request.getServerName()+":"+request.getServerPort()+path+"/";
Trying, I changed the source code and then re-typed the jar package, commit svn, jenkins compiled and deployed and found that it did not work. Think of maven, all jar packages come from the platform's private repository, which...
Another way of thinking, write a java class inheritance, the result of a look at the corresponding logic where the function, private, look up again at class, final, 10,000 beasts of God ah!!!
What object-oriented, simple, rough, source code copy, revised named MySsoFilter.java, in the replacement of the project configuration file we wrote filter, svn commit, jenkins immediately build deployment, the world is quiet from now on.
Reference and thanks
Reference list
- Tomcat configuration single machine multi-instance: This article is concise and powerful, is a model of technical blog!
- Suse port redirection
- Method of Opening Port under Suse
Thank the small partners of the project team for their hard work in troubleshooting defects and writing new filter s.
Thank Reboot's classmates for pointing out the direction at the critical moment.
Thanks to Reboot's Architect Course and Operational Automation Course, the former broadened my horizons and the latter helped me harvest the docker artifact.
docker + k8s
This course is a live webcast course. It lasts for more than two months and lasts 10 hours, one full day a week. Additional: Video recording + Notes + Question answering time (7 times +) in addition to the classroom, 2019-1-13, the original price is 5800, and the current anniversary activity 100 deposit is 800.
Course Lecturer: Teacher GY
Ten years of front-line software development experience, has experienced traditional security companies, as well as a number of Internet companies; in security development, has developed Linux firewall, web application firewall, Linux security kernel reinforcement, based on large-traffic Web security threat analysis and other projects; in the work of Internet companies, has been based on DPDK high-performance network development framework development based on full-flow. Quantity network traffic analysis platform and Sflow-based network traffic analysis platform, Smart DNS based on Golang, etc. Development language is also from C-> python-> golang transformation process? Now engaged in research and development of private cloud platform based on K8S and Docker; rich experience in Linux system development, network development and project management; at present, 90% of the development work is using Golang, which is a concise, efficient, powerful and flexible programming language.
For the specific content of the course, add a small assistant WeChat: 17812796384 for consultation.
This article is authorized by the author: Barbarian
Links: https://opsdev.fun/2017/08/01/O1-8-05-Docker%E5%BF%AB%E9%80%9F%E9%AA%8C%E8%AF%81tomcat%E5%8D%95%E6%9C%BA%E5%A4%9A%E5%AE%9E%E4%BE%8B%E6%96%B9%E6%A1%88/
Copyright belongs to the author.
Please contact the author for authorization to reprint.